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Preface 



Large and complex software systems provide the necessary infrastucture in all in- 
dustries today. In order to construct such large systems in a systematic manner, 
the focus in the development methodologies has switched in the last two decades 
from functional issues to structural issues: both data and functions are encap- 
sulated into software units that are integrated into large systems by means of 
various techniques supporting reusability and modifiability. This encapsulation 
principle is essential to both the object-oriented and the more recent component- 
based software engineering paradigms. 

Formal methods have been applied successfully to the verification of medium- 
sized programs in protocol and hardware design. However, their application to 
large systems requires a further development of specification and verification 
techniques supporting the concepts of reusability and modifiability. 

In order to bring together researchers and practioners in the areas of soft- 
ware engineering and formal methods, we organized the 2nd International Sym- 
posium on Formal Methods for Components and Objects (FMCO) in Leiden, 
The Netherlands, from November 4 to 7, 2003. The program consisted of in- 
vited tutorials and technical presentations given by leading experts in the fields 
of theoretical computer science and software engineering. The symposium was 
attended by more than 80 people from all over the world. 

This volume contains the contributions of the invited speakers to 
FMCO 2003. We believe that the presented material provides a unique com- 
bination of ideas on software engineering and formal methods which we hope 
will form an inspiration for those aiming at further bridging the gap between 
the theory and practice of software engineering. 

The very idea to organize FMCO arose out of the NWO/DFG bilateral 
project Mobi-J. In particular we acknowledge the financial support of the NWO 
funding of Mobi-J. Additional financial support was provided by the Lorentz 
Center, the 1ST project Omega (2001-33522), the Dutch Institute for Program- 
ming Research and Algorithmics (IPA), the Royal Netherlands Academy of Arts 
and Sciences (KNAW), the Centrum voor Wiskunde en Informatica (CWI), and 
the Leiden Institute of Advanced Computer Science (LIACS). 



July 2004 F.S. de Boer 

M.M. Bonsangue 
S. Graf 
W.-P. de Roever 
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The Mobi-J Project 

Mobi-J is a project funded by a bilateral research program of the Dutch Orga- 
nization for Scientific Research (NWO) and the Central Public Funding Orga- 
nization for Academic Research in Germany (DFG). 

The partners of the Mobi-J projects are: 

— Centrum voor Wiskunde en Informatica (F.S. de Boer) 

— Leiden Institute of Advanced Computer Science (M.M. Bonsangue) 

— Christian-Albrechts-Universitat Kiel (W.-P. de Roever) 

This project aims at the development of a programming environment which 
supports component-based design and verification of Java programs annotated 
with assertions. The overall approach is based on an extension of the Java lan- 
guage called Mobi-J with a notion of component which provides for the encapsu- 
lation of its internal processing of date and composition in a network by means 
of mobile asynchronous channels. 

The activities of Mobi-J include the organization of international symposia 
funded by the NWO and Ph.D. research funded by the DFG. By means of regular 
meetings the partners discuss intensively Ph.D. research involving Mobi-J related 
topics. Mobi-J also maintains contacts with other German universities, including 
the universities of Oldenburg and Munich, and a close collaboration with the 
European 1ST project OMEGA. 



The Omega Project 

The overall aim of the European 1ST project Omega (2001-33522) is the defini- 
tion of a development methodology in UML for embedded and real-time systems 
based on formal verification techniques. The approach is based on a formal se- 
mantics of a suitable subset of UML, adapted and extended where needed with 
a special emphasis on time-related aspects. 

The Omega project involves the following partners: VERIMAG (France, Go- 
ordinator), Gentrum voor Wiskunde en Informatica (The Netherlands), Ghrist- 
ian-Albrechts-Universitat (Germany), University of Nijmegen (The Netherlands), 
Weizmann Institute (Israel), OFFIS (Germany), EADS Launch Vehicles (France), 
France Telecom R&D (France), Israeli Aircraft Industries (Israel), and National 
Aerospace Laboratory (The Netherlands). 
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Abstract. Recently we proposed a mathematical framework offering 
diverse models of computation and a formal foundation for correct-by- 
construction deployment of synchronous designs over distributed 
architecture (such as GALS or LTTA). In this paper, we extend our 
framework to model explicitly causality relations and scheduling con- 
straints. We show how the formal results on the preservation of seman- 
tics hold also for these cases and we discuss the overall contribution in 
the context of previous work on desynchronization. 



1 Introduction 

Embedded systems are intrinsically heterogeneous since they are based on pro- 
cessors that see the world digitally and an environment that is analog. In ad- 
dition, the processing elements are heterogeneous too since they often include 
micro-controllers and digital signal processors in addition to special purpose com- 
puting engines. These parts must communicate and exchange information in a 
consistent and reliable way over media that are often noisy and unreliable. Some 
of the tasks that embedded systems must carry out are safety-critical, e.g., in 
medical and transportation systems (cars, airplanes, trains) and for this reason 
have hard constraints on timing and reliability. As technology advances, increas- 
ingly more computing power becomes available thus offering the opportunity of 
adding functionality to the system to such an extent that the complexity of the 
design task is unmanegeable without a rigorous design methodology based on 



* This research was supported in part by the European Commission under the projects 
COLUMBUS, IST-2002-38314, and ARTIST, IST-2001-34820, by the NSF under the 
project ITR (CCR-0225610), and by the GSRC. 



F.S. de Boer et al. (Eds.): FMCO 2003, LNCS 3188, pp. 1-16, 2004. 
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sound principles. In particular, the need for fast time-to-market and reasonable 
development cost imposes design re-use. And design re-use implies the use of 
software for as many parts of the functionality as possible given size, production 
cost and power consumption constraints. Consequently, software accounts for 
most of the design costs today and it is responsible for delays in product deliv- 
ery because of the lack of a unified design process that can guarantee correct 
behavior. 

Today, designers face a very diversified landscape when it comes to method- 
ologies, supporting tools, and engineering best practices. This would not neces- 
sarily be a problem if it were not for the fact that transitioning between tools 
that are based on different paradigms is increasingly becoming a design produc- 
tivity bottleneck as it has been underlined by the road map work performed 
in the framework of the ARTIST network of excellence [3]. A solution to this 
problem would be to impose a “homogeneous” design policy, such as the fully 
synchronous approach. However, implementation costs in terms of performance 
and components require a more diversified view. Heterogeneity will manifest it- 
self at the component level where different models of computation may be used 
to represent component operation and, more frequently, at different levels of 
abstraction, where, for example, a synchronous-language specification of the de- 
sign may be refined into a globally asynchronous locally synchronous (GALS) 
architecture, thus alleviating some of the cost issues outlined above. Having 
a mathematical framework for the heterogeneous modeling of reactive systems 
gives freedom of choice between different synchronization policies at different 
stages of the design process and provides a solid foundation to handle formally 
communication and coordination among heterogeneous components. Interest- 
ing work along similar lines has been the Ptolemy project [13, 15], the MoBIES 
project [1], the Model-Integrated Computing (MIC) framework [16], and Inter- 
face Theories [14]. 

This paper is an extension of [7] where we proposed Tagged Systems, a vari- 
ation of Lee and Sangiovanni-Vincentelli’s (LSV) Tagged-Signal Model [22], as 
a mathematical model for heterogeneous systems. Originally, we restricted our- 
selves to Tagged Systems in which parallel composition is by intersection, mean- 
ing that unifiable events of each component must have identical variable, data, 
and tag. While this restriction has allowed us to handle GALS models of design, it 
does not cover all cases of interest. For example, causality relations and schedul- 
ing constraints are not compatible with parallel composition by intersection. 
Neither are earliest execution times. Yet causality and scheduling constraints 
are very important to include when implementing an embedded systems. Hence, 
it is sometimes useful to have a notion of parallel composition that accepts the 
unification of events having different tags (while the data that they carry must 
still be equal) . In this work, we propose an extension of Tagged Systems where 
the unification rule for tags is itself parameterized. We show that this model cap- 
tures important properties such as causality and scheduling constraints. Then, 
we extend the general theorems of [7] on the preservation of semantics during 
distributed deployment. 
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2 Tagged Systems and Heterogeneous Systems 

2.1 Tagged Systems and Their Parallel Composition 

Throughout this paper, N = { 1 , 2 ,...} denotes the set of positive integers; N 
is equipped with its usual total order <. X Y denotes the set of all partial 
functions from X to Y. If {X, <x) and (T, <v) are partial orders, f G X Y 
is called increasing if /(<x) C <y, i.e., \/x,x' G X : x <x x' ^ f{x) <y 

Tag Structures. A tag structure is a triple (T, <,C), where T is a set of tags, 
and < and C are two partial orders. Partial order < relates tags seen as time 
stamps. Call a clock any increasing function (N, <) (T, <). Partial order C, 

called the unification order, defines how to unify tags and is essential to express 
coordination among events. Write t\ cxi t 2 to mean that there exists t G T 
such that Ti C T. We assume that any pair (ti,T 2) of tags, such that n tx T2 
holds, possesses an upper bound. We denote it by ti Ut 2. In other words, (T, C) 
is a sup-semi-lattice. We call cxi and U the unification relation and unification 
map, respectively. 

We assume that unification is causal with respect to partial order of time 
stamps: the result of the unification cannot occur prior in time than its con- 
stituents. Formally, if t\ ixi t 2 is a unifiable pair then Ti < {t\ U T2), for i = 1 , 2 . 
Equivalently: 

Vr, r': t\Zt' t<t'. ( 1 ) 

Condition ( 1 ) has the following consequence: if n < r{, T2 < r^, Ti ix t 2, 
and tc together hold, then (n U T2) < (r{ U T2) must also hold. This 
ensures that the system obtained via parallel composition preserves the agreed 
order of its components. 

Tagged Systems. Let V be an underlying set of variables with domain D. For 
P C V finite, a V -behaviour, or simply behaviour, is an element: 

a G V ^ {T X D), ( 2 ) 

meaning that, for each v G V , the n-th occurrence of v in behaviour a has tag 
T G T and value x G D. For v a variable, the map a{v) S N (T x H) is called 
a signal. For a a behaviour, an event of cr is a tuple (u, n, r, a;) G P x N x T x D 
such that a{v){n) = (t,x). Thus we can regard behaviours as sets of events. We 
require that, for each v G V , the first projection of the map cr(v) (it is a map 
N 1 -^ T) is increasing. Thus it is a clock and we call it the clock of v in a. A 
tagged system is a triple P = (P, T, X), where P is a finite set of variables, T is 
a tag structure, and S a set of P-behaviours. 

Homogeneous Parallel Composition. Consider two tagged systems Pi = (Pi,Ti, 
Si) and P2 = (P2, S2) with identical tag structures 7 } = 72 = T. Let U be the 

unification function of T. For two events e = {v,n,T,x) and e' = {v' ,n' ,t' ,x'), 
define 

e CXI e' iff v = v',n = n',T cx t' , x = x' , and 

e CXI e' eU e' =de{ {v,n,T U t' , x). 
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The unification map U and relation cxi extend point- wise to behaviours. 
Then, for a a ^-behaviour and and a' a f4'-behaviour, define, by abuse of nota- 
tion: (7 CXI cr' iff a^Ynv' cr^ivnyo ^md then 



crUcr' =def (crivaV' U \Vr\V') U CT|y\y' U cr'\v'\V- 

where CT|vv denotes the restriction of behaviour a to the variables of W. Finally, 
for S and S' two sets of behaviours, define their conjunction 

S A S' =def {crUa' \ a G S , a' G S' and a ixi cr'} (3) 

The homogeneous parallel composition of P\ and P2 is 

Pi II P2 =def (Vi U 4^2, T, A S2) (4) 



2.2 Theme and Variations on the Pair {'T, U) 

Parallel Composition by Intersection. This is the usual case, already in- 
vestigated in [7]. It corresponds to: 

— The tag set T is arbitrary. 

— The unification function U is such that r cx r' iff t = r', and t U r' =def t . 

Modeling synchronous systems, asynchronous systems, timed systems, with 
this framework, is extensively discussed in [7]. We summarize here the main 
points. 

To represent synchronous systems with our model, take for T a totally or- 
dered set (e.g., T = N), and require that all clocks are strictly increasing. The 
tag index set T organizes behaviours into successive reactions, as explained next. 
Call reaction a maximal set of events of cr with identical t. Since clocks are 
strictly increasing, no two events of the same reaction can have the same vari- 
able. Regard a behaviour as a sequence of global reactions: a = ai, U2-, ■ ■ ., with 
tags Ti, T2, . . . G T. Thus T provides a global, logical time basis. 

As for asynchronous systems, we take a very liberal interpretation for them. 
If we interpret a tag set as a constraint on the coordination of different signals of 
a system and the integer n G N as the basic constraint of the sequence of events 
of the behaviour of a variable, then the most “coordination unconstrained” sys- 
tem, the one with most degrees of freedom in terms of choice of coordination 
mechanism, could be considered an ideal asynchronous system. Then an asyn- 
chronous system corresponds to a model where the tag set does not give any 
information on the absolute or relative ordering of events. In more formal way, 
take T = {.}, the trivial set consisting of a single element. Then, behaviours 
identify with elements ct G V 1-^ N D. 

Capturing Causality Relations and Scheduling Specifications. How can 

we capture causalities relations or scheduling specifications in the above in- 
troduced asynchronous tagged systems? The intent is, for example, to state 




Causality and Scheduling Constraints 



5 



that “the 2nd occurrence of x depends on the 3rd occurrence of Define 
No =det N U {0}. Define a dependency to be a map: 

^ = V ^ No. 

We denote by A the set of all dependencies, and we take T = A. Thus an 
event has the form: 



e= (v,n,6,x), (5) 

with the following interpretation: event e has v as associated variable, it is ranked 
n among the events with variable v, and it depends on the event of variable w 
that is ranked 6(w). The special case 6(w) = 0 is interpreted as the absence of 
dependency. We take the convention that, for e as in (5), 6(v) = n — 1. Thus, 
on cr(v), the set of dependencies reproduces the ranking. A is equipped with 
the partial order defined by ^ iff Vv : 6(v) < 6'(v). Then we define the 
unification map U for this case: 

dom (U) = T X T and ^ U =def max(5. S'). (6) 

With this definition, behaviours become labelled preorders as explained next. 
For a a behaviour, and e, e' two events of a, write: 

(v, n, S, x) 

(v',n',S',x') (7) 

n' 

Note that, since n' > 0, the condition 6{v') = n' makes this dependency 
effective. Definition (7) makes a a labeled directed graph. Denote by Aa the 
transitive reflexive closure of it is a preorder ^ . 

Capturing Earliest Execution Times. Here we capture earliest timed execu- 
tions of concurrent systems. Take T = R+, the set of non-negative real numbers. 
Thus a tag r G T assigns a date, and we define 

tUt' =def max(r, /)• 

Hence U is here a total function. Composing two systems has the effect that 
the two components wait for the latest date of occurrence for each shared vari- 
able. For example, assume that variable v is an output of P and an input of 
Q in P\\Q. Then the earliest possible date of every event of variable u in Q is 
by convention 0, whereas each event associated to v has a certain date of pro- 
duction in P. In the parallel composition P |j Q, the dates of production by P 
prevail. 




^ We insist: “preorder”, not “partial order” — this should not be a surprise, since the 
superposition of two partial orders generally yields a preorder. 
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Capturing Timed Systems. Various classes of timed automata models have 
been proposed since their introduction by Alur and Dill in [ 2 ] . In timed automata, 
dates of events are subject to constraints of the form C : r G U i], where 

I is some finite set whose cardinality depends on the considered event, and 
I = [ or (, and symmetrically for ]. The classes of timed automata differ by 
the type of constraint that can be expressed, and therefore they differ in their 
decidability properties. Nevertheless, they can all be described by the following 
kind of Tagged System^. 

Take T = Pow;(R+), where Pow denotes powerset. Thus, a tag t & T assigns 
to each event a constraint on its possible dates of occurrence. Then, several 
definitions are of interest: 

— Ti (XI T2 iff Ti n T2 yf 0 , and n U T2 = ti n T2. This is the straightforward 
definition, it consists in regarding tags as constraints and combining them 
by taking their conjunction. 

~ the unification of tags is a total function, defined as follows: ti U T2 = 
{max(ti, ^2)1^1 G Ti, ^2 G T2}. In this case, events are synchronized by waiting 
for the latest one. 

Hybrid Tags. Define the product (T, U) =def {T' ^ U') x (T", U") in a standard 
way. This allows us to combine different tags into a compound, heterogeneous, 
tag. For instance, one can consider synchronous systems that are timed and en- 
hanced with causality relations. Such systems can be “desynchronized” , meaning 
that their reaction tag is erased, but their causality and time tags are kept. 



2.3 Running Example 

The Base Case: Synchronous Systems. Let P and Q be two synchronous systems 
involving the same set of variables: b of type boolean, and x of type integer. Each 
system possesses only a single behaviour, shown on the right hand side of P : . . . 
and Q : . . ., respectively. Each behaviour consists of a sequence of successive 
reactions, separated by vertical bars. Each reaction consists of an assignment of 
values to a subset of the variables; a blank indicates the absence of the considered 
variable in the considered reaction. 



b : 


t 


f 


t 


f 


t 


f 




X : 


1 




1 




1 






b : 

X : 


t 


/ 

1 


t 


f 

1 


t 


f 

1 





The single behavior of P can be expressed formally in our framework as 

CT(6)(2n - 1) = (2n - l,t) , cr(5)(2n) = (2n, /) , . 

a{x){n) =(2n — 1,1) ' ' 

^ Our framework of Tagged Systems handles (infinite) behaviours and is not suited 
to investigate decidability properties, this explains why we can subsume all variants 
of timed automata into a unique Tagged Systems model. 
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where we take T = N to index the successive reactions. Note the absence of x 
at tag 2n. Similarly, for Q we have the following where x is absent at tag 2n— 1: 

cr(6)(2n - 1) = (2n- l,t) , cr(5)(2n) = (2n, /) . . 

a{x){n) =(2n,l) ^ ^ 

Now, the synchronous parallel composition of P and Q, defined by intersec- 
tion: P II Q =def Pr\Q, is empty. The reason is that P and Q disagree on where 
to put absences for the variable x. Formally, they disagree on their respective 
tags. 



Desynchronizing the Base Case. The desynchronization of a synchronous system 
like P or Q consists in (z) removing the synchronization barriers separating the 
successive reactions, and, then, {ii) compressing the sequence of values for each 
variable, individually. This yields: 



b ■■ t f t ft f .. 

■ X : 1 1 1 . . 



where the subscript a refers to asynchrony. The reader may think that events 
having identical index for different variables are aligned, but this is not the 
case. In fact, as the absence of vertical bars in the diagram suggests, there is no 
alignment at all between events associated with different variables. 

Formally, we express asynchrony by taking T = {.}, the trivial set with a 
single element. The reason is that we do not need any additional time stamping 
information. Thus, the single behavior of Pa = Qa is written as 



aa{b){2n — 1) = t, (Ja{b){2n) = /, and aa(x)(n) = 1. (10) 



Regarding desynchronization, the following comments are in order. Note that 
P Q but Pa = Qa- Next, the synchronous system R defined by i? = PLiQ, the 
nondeterministic choice between P and Q, possesses two behaviours. However, its 
desynchronization Ra equals Pa, and possesses only one behaviour. Now, since 
Pa = Qa, then Pa II Qa =def Pa Qa = Pa = Q a 0- Thus, for the pair (P, Q), 

desynchronization does not preserve the semantics of parallel composition, in 
any reasonable sense. 

Adding Causality Relations. Suppose that some analysis of the considered pro- 
gram allows us to add the following causality relations to P and Q: 



b : 

X : 


t 

i 

1 


f 


t 

i 

1 


f 


t 

i 

1 


f 




b : 
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f 


t 


f 


t 


f 








i 




i 




i 




X : 




1 




1 




1 
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For example, in accordance to the above causality relations, the meaning of 
P could be: ii b = t then get x (and similarly for Q) . By using the dependency 
relation defined in (6), we can express formally the behavior of Pc as 

CT(6)(2n- 1) = ([2n- l,(a;,0)],t) , cr(&)(2n) = ([2n, (x, 0)], /) 

a{x){n) = ([2n- l,(5,2n- 1)],1) 

and the behavior of Qc as 

cr(5)(2n- 1) = ([2n- l,(a;,0)],t) , cr(6)(2n) = ([2n, (a;, 0)], /) 

, cr(x)(n) = ([2n, (5,2n)],l) 

As for the base case and for the same reason. Pc || Qc = 0- 

Then, Desynchronizing. Removing the synchronization barriers from Pc and Qc 
yields 



b 


: t 
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f 


t 


/••• 




i 
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i 




X : 


: 1 
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1 




b : 


t 


/ 


t 


f 


t 


/••• 






i 




1 




i ••• 


X : 




1 




1 




1 ... 



We insist that, again, desynchronizing consists in (z) removing the synchro- 
nization barriers, and then (ii) compressing the sequence of values for each 
variable, individually — this last step is not shown on the drawing, just because 
it is a lot easier to draw vertical arrows. Formally, for P“ we have 

a(b)(2n-l) = ((x,0),t) , a(b)(2n) = ((x,0), f) 

a(x)(n) = i(b,2n- 1),1) 

and, for we have 

cr(5)(2n - 1) = ((x, 0), t) , cr(5)(2n) = ((a;, 0), /) 

, cr(a;)(n) = ((b,2n),l) 

These two behaviours are unifiable and yield the dependency (b,2n), by the 
max rule (6). In fact, the reader can check that P“ || = Q“. Thus Pc and 

Qc did not include enough causality relations for desynchronization to properly 
preserve the semantics. 

Adding More Causality Relations. Suppose that “oblique” causality relations are 
added, from each previous occurrence of x to the current occurrence of b: 



b : 
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These supplementary causality relations conform to the synchronous model 
since they agree with the increasing reaction index. Formally, the single behavior 
of Pec is written 

cr(6)(2n- 1) = ([2n- l,(a;,0)],t) , a{b){2n) = {[2n, (x,n)], f) 

a{x){n) = ([2n- l,(6,2n- 1)],1) 

and the one of Qcc is 

cr(5)(2n- 1) = ([2n- l,(a:,n- l)],t) , cr(6)(2n) = ([2n, (a:, 0)], /) 

, cr(x)(n) = ([2n, (5,2n)],l) 

Again, II Qcc = 0- 

Then, Again Desynchronizing. Removing the synchronization barriers from Pec 
and Qcc yields 



b : 


: t 


ft 


ft /... 




i 


/ i/ i/ ••• 


X : 


: 1 


1 


1 


b : 




t f 


tf tf... 






1 / 


i/ i--- 


X : 




1 


1 1 ... 



In our framework, for we have 

cr(6)(2n - 1) = ((x,0),t) , a{b){2n) = {{x,n),f) 

a{x){n) = ((6,2n- 1),1) 

and, for we have 

cr(5)(2n- 1) = ((a;,n- l),t) , cr(5)(2n) = ((a;, 0), /) 

, cr(a;)(n) =((6,2n),l) 

However, now the composed behavior does not coincide with but is 



b : t f t f t f . . . 

pnQ^c= 1/ 1/ I--- 

x: 1 1 1 ... 



The reason for the double causality between x and /-occurrences of b is that 
the n-th x causes the (2n)-th b (i.e. the n-th /-occurrence of b) in Pec whereas the 
(2n)-th b causes the n-th x in Qcc- Formally, by the max rule (6), the composed 
behavior of P^ || Q/^ is written 

cr(5)(2n- 1) = ((a;,n- l),t) , cr(5)(2n) = ((x, n), /) 

, cr(x)(n) =((6,2n),l) 

In conclusion, P^“ || Q“^ possesses causality loops and may be considered 
pathological and thus “rejected” in accordance with the original semantics 

P||Q = 0. 
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2.4 Heterogeneous Systems 

Assume a functional system specification using a synchronous approach, for sub- 
sequent deployment over a distributed asynchronous architecture (synchronous 
and asynchronous are considered in the sense of subsection 2.1). When we de- 
ploy the design on a different architecture, we must make sure that the original 
intent of the designer is maintained. This step is non trivial because the infor- 
mation on what is considered correct behaviour is captured in the synchronous 
specifications that we want to relax in the first place. We introduce the no- 
tion of semantic-preserving transformation to identify precisely what is a correct 
deployment. We present the idea with our running example: 

Running Example, Cant’d. Regarding semantics preserving deployment, the fol- 
lowing comments can be stated on our running example. The synchronous paral- 
lel composition of P and Q, defined by intersection: P || Q =def P n Q, is empty. 
The reason is that P and Q disagree on where to put absences for the variable x. 
On the other hand, since Pa = Qa, then Pa || Qa =def Pa<^Qa = Pa = Qa ^ 0 - 
Thus, for the pair (P,Q), desynchronization does not preserve the semantics of 
parallel composition, in any reasonable sense. O 

How to model that semantics is preserved when replacing the ideal syn- 
chronous broadcast by the actual asynchronous communication? An elegant so- 
lution was proposed by Le Guernic and Talpin for the former GALS case [21]. 
We cast their approach in the framework of tagged systems and we generalize 
it. 

Tag Morphisms. For T, T' two tag structures, call morphism a map p \T ^ 
T' which is increasing w.r.t. < and <’ , surjective, and such that 

poU = U' o{p,p) (11) 

holds, where o denotes the composition of functions. As expected from their 
name, morphisms compose. For p : T i— > T' a morphism, and ct G G i— > N i-^ 
X D) a, behaviour, replacing t by p(r) in cr defines a new behaviour having 
T' as tag set. We denote it by 

CTp, or by crop. (12) 

Performing this for every behaviour of a tag system P yields the tag system 

Pp- (13) 

For 7i T <111- 72 two morphisms, define: 

Pi PlXp2 P2 =def { (n,T 2 ) I Pi(ti) = P 2 (t 2 ) } . (14) 

A case of interest is 7) = T( x T ,i = 1,2, and the T( are different. Then 

Ti pjXp 2 T 2 identifies with the product T(xT x 7^'. For example, the desynchro- 
nization of synchronous systems is captured by the morphism a : T^ynch {-jj 
which erases all global timing information (see Equations (8,9), and (10)). 
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Heterogeneous Parallel Composition. In this subsection we define the com- 
position of two tagged systems Pi = Si),i = 1, 2, when 71 yf 7^. Assume 

two morphisms 71 T 71 . Write: 

O'! Pl^P2 ^2 iff CTiopi [XI CT20P2- (15) 

For (cri,CT 2 ) a pair satisfying (15), define 

pjUp2 (72 (16) 

as being the set of events (v, n, (ri, T 2 ), a;) such that Pi(ti) = ^ 2 ( 72 ) =def t 
and (u,n,T, x) is an event of (Ti o U (T 2 ° p 2 • We are now ready to define the 
heterogeneous conjunction of Si and S 2 by: 

p\t\p2 S2 — def { pil-^P2 ^2 I t 7 i p,t^P2 ^2 } ■ (1^) 

Finally, the heterogeneous parallel composition of Pi and P 2 is defined by: 

-f’l (pi Ilp 2 ) -P 2 = ( hi U V 2 , Ti piXp 2 71 , Si pjAp 2 S 2 ) . (18) 

We simply write (pj| instead of (pj|p 2 ) when p 2 is the identity. 

GALS, Hybrid Timed/Untimed Systems, and More. To model the in- 
teraction of a synchronous system with its asynchronous environment, take the 
heterogeneous composition P(q,|| A, where P = {V,%ync\nS) is a synchronous 
system, A = (W, {.}, S') is an asynchronous model of the environment, and 

a : Tlynch {•} is the trivial morphism, mapping synchrony to asynchrony 

(hence the special notation) . 

For GALS, take 7) = 71 = Tlynch, where Tlynch is the tag set of synchronous 
systems. Then, take T = {.} is the tag set of asynchronous ones. Take a : 
%ynch '^ {•}) the trivial morphism. And consider Pi (q||q.) P 2 . 

For timed/untimed systems, consider P (p|| Q, where P = (P, Tly^ch x AT) 
is a synchronous timed system, Q = {W, Tlynch, S') is a synchronous but untimed 
system, and p : 71y„ch x T^, i-^- Tlynch is the projection morphism. 

This machinery of morphisms provides a framework for the different manip- 
ulations of tags that were performed in Section 2.3 on our running example. 



3 Application to Correct Deployment 

In this section we apply our framework to the formalization of the practically 
important — but generally informal — requirement of “correct deployment” . 

3.1 Preserving Semantics: Formalization 

We are given a pair Pi = (Vi,Ti, Si),i = 1,2, such that 7) = 71, and a pair 
7) -A—>- T 7 ^ of identical morphisms. We can consider two semantics: 

The strong semantics : Pi || P 2 
The weak semantics : Pi (p||p) P 2 . 
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We say that p is semantics preserving with respect to P\ |j P 2 if 

Pi(,||,)P 2 ^ P 1 IIP 2 . (19) 

Running Example, Cant’d. The reader can check the following as an exercise: 
P\\Q = 0, and, as we already discussed, Pa\\Qa = Pa- Now we compute 
P (alU) Q- From (16) we get that, using obvious notations, (ap,aQ) is a pair of 
behaviours that are unifiable modulo desynchronization, i.e., ap qIxIq, ctq. Then, 
unifying these yields the behaviour cr such that: 

Vn G N : a(b)(n) = ((n, n),Vb) and a{x){n) = ((2n — 1, 2n), 1) (20) 

where Vb = t if n is odd, and Uh = / if n is even. In (20), the expression for 
a{b)(n) reveals that desynchronizing causes no distortion of logical time for b, 
since (n, n) attaches the same tag to the two behaviours for unification. On 
the other hand, the expression for a(x)(n) reveals that desynchronizing actually 
causes distortion of logical time for x, since (2n — l,2n) attaches different tags 
to the two behaviours for unification. Thus P || Q = 0, but P (q||q,) Q consists 
of the single behaviour defined in (20). Hence, P (q,||q) Q ^ P || Q in this case: 
semantics is not preserved. O 



3.2 A General Result on Correct Deployment 

Here we analyse requirement (19). The following theorem holds (see (13) for the 
notation Pp used in this theorem): 

Theorem 1. The pair (Pi,P 2 ) satisfies condition (19) if it satisfies the follow- 
ing two conditions: 



Vf G {1, 2} : (Pi)p is in bijection with Pi (21) 

{Pi II P2)p = {Pl)p II {P2)p (22) 

Comments. The primary application of this general theorem is when P and Q 
are synchronous systems, and p = a is the desynchronization morphism. This 
formalizes GALS deployment. Thus, Theorem 1 provides sufficient conditions 
to ensure correct GALS deployment. Gonditions (21) and (22) are not effective 
because they involve (infinite) behaviours. In [5,6], for GALS deployment, con- 
dition (21) was shown equivalent to some condition called endochrony, expressed 
in terms of the transition relation, not in terms of behaviours. Similarly, con- 
dition (22) was shown equivalent to some condition called isochrony, expressed 
in terms of the pair of transition relations, not in terms of pairs of sets of be- 
haviours. Endochrony and isochrony are model checkable and synthesizable, at 
least for synchronous programs involving only finite data types (see [5, 6] for a 
precise statement of these conditions) . 

Proof. Inclusion D in (19) always hold, meaning that every pair of behaviours 
unifiable in the right hand side of (19) is also unifiable in the left hand side. 
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Thus it remains to show that, if the two conditions of Theorem 1 hold, then 
inclusion C in (19) does too. Now, assume (21) and (22). Pick a pair (cri,cr 2 ) 
of behaviours which are unifiable in Pi (p||p) Pj- Then, by definition of (p||p) , 
the pair ((cri)p, (cr 2 )p) is unifiable in (Pi)p || (p 2 )p- Next, (22) guarantees that 
(cti)p U ((T 2 )p is a behaviour of {Pi\\P 2 )p- Hence there must exist some pair 
(cr(,(T 2 ) unifiable in Pi || P 2 , such that (fT(UCT 2 )p = (cri)p U (cr 2 )p- Using the 
same argument as before, we derive that {{<j'i)p, (o' 2 )p) is also unifiable with re- 
spect to its associated (asynchronous) parallel composition, and (cri)p U {<j' 2 )p = 
(cti)p U ((T 2 )p. But ((j()p is the restriction of (cr()p U (ct 2 )p to its events labeled by 
variables belonging to Vi, and similarly for {<J 2 )p. Thus (cr')p = (CTi)p for t = 1,2 
follows. Finally, using (21), we know that if (ct(,(T 2 ) is such that, for i = 1,2: 
(cr')p = (cTj)p, then: ct' = Gi. Hence (cri,cr 2 ) is unifiable in Pi |j P 2 . O 

Corollary 1. Let P\ and P 2 he synchronous systems whose behaviors are 

equipped with some equivalence relation and assume that P\ and P 2 are closed 
with respect to Then, the pair (Pi,P 2 ) satisfies condition (19) if it satisfies 
the following two conditions: 

Vz G {1,2} : {Pi)p is in bijection with Pi/~ (23) 

(Pi II P2)^ = (Pl)p II (P2)p (24) 

where Pi/ ^ is the quotient of Pi modulo ~ . 

Proof. Identical to the proof of Theorem 1 until the paragraph starting with 
“Finally”. Finally, using (23), we know that if (cr},cr 2 ) is such that, for z = 1,2: 
((t')p = ((Ti)p, then: cr' ~ Hence (cri,cr 2 ) is unifiable in Pi || P 2 , since all 
synchronous systems we consider are closed under ~. O 

This result is of particular interest when ~ is the equivalence modulo stut- 
tering, defined in [7]. 

Running Example, Cont’d. Since P and Q possess a single behaviour, they 
clearly satisfy condition (21). However, the alternative condition (22) is vio- 
lated: the left hand side is empty, while the right hand side is not. This explains 
why semantics is not preserved by desynchronization, for this example. In fact, 
it can be shown that the pair (P, Q) is not isochronous in the sense of [5, 6]. 

More Examples and Counter-Examples. Our running example was a counter- 
example where condition (22) is violated. 

For the following counter-example, condition (21) is violated: P emits to Q 
two signals with names x and y. Signal y is emitted by P if and only if x > 0 
(assuming, say, x integer). Signals x and y are awaited by Q. Formally: 

f cr(x)(n) = (rz,-) 

P : < a{y){n) = (m(zz),— ), where 

[ m(n) = minjm | m > m{n — 1) A a(x)(m) > 0} 



. / cr(x)(rz) = (k(n),-) 
^■\a(y)(n)=(l(n),-) 
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In (25), symbol — denotes an arbitrary value in the domain D, and 
are arbitrary strictly increasing maps, from N to N. As the reader can check, P 
satisfies (21) but Q does not. The desynchronization a is not semantics preserv- 
ing for this pair (P,Q). 

Now, consider the following modification of {P, Q): P' emits to Q' two signals 
with names x and y. Signal y is emitted by P' if and only if a; > 0 (assuming, say, 
X integer). In addition, P' emits a boolean guard b simultaneously with x, and b 
takes the value true iff x > 0. Signals x and y are awaited by Q' . In addition, Q' 
awaits the boolean guard b simultaneously with x, and Q' knows that he should 
receive y simultaneously with the true occurrences of b. Formally: 



{ CT(x)(n) = (n,-) 

a{b){n) = if a(x)(n)(n) > 0 then (n, f) else (n, /) 
<j{y){n) = (m(n),— ), where 

m{n) = min{m | m > m{n — 1) A a{x){m) > 0} 

f = (fc(n),-) 

I a{b){n) = {k{n),-) 

I cr(?/)(n) = (Z(n),-), where 

[ l{n) = min{fc(m) | k{m) > l{n — 1) A a{b){m) = t} 



(26) 



The guard b explicitly says when y must be awaited by Q' , this guarantees 
that Q' satisfies (21) (and so does P'). On the other hand, the pair {P',Q') 
satisfies (22). Thus the modified pair (P', Q') is semantics preserving, for desyn- 
chronization. The modification, from (P, Q) to (P', Q'), has been by adding the 
explicit guard b. This can be made systematic, as outlined in [6]. 



4 Discussion and Perspectives 

In [11] the following result was proved. For P and Q two synchronous systems 
such that both P, Q, and P || Q are functional, clock-consistent, and with loop- 
free combinational part, then P jj Q can be seen as a Kahn network — for our 
purpose, just interpret Kahn networks as functional asynchronous systems. This 
result applies to functional systems with inputs and outputs, it gives no help 
for partial designs or abstractions. Our conditions of endochrony and isochrony 
allows us to deal even with partial designs, not only with executable programs. 
Hence, they do represent effective techniques that can be used as part of the 
formal foundation for a successive-refinement design methodology. 

As said before, this paper extends the ideas of [21] on desynchronization. A 
more naive “token-based” argument to explain GALS deployment is also found 
in [8], Sect. V.B. This argument is closely related to the use of Marked Graphs 
in [12] to justify GALS desynchronization in hardware. 

Another example can be found in theory of latency-insensitive design [10]: 
here, if P || Q is a specification of a synchronous system and P and Q are stallable 
processes, then it is always possible to automatically derive two corresponding 
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patient processes Pp and Qp that seamlessly compose to give a system imple- 
mentation Pp II Qp that preserves semantics while being also robust to arbitrary, 
but discrete, latency variations between P and Q. Again, Pp\\Qp is a correct 
deterministic executable system made of endochronous sub-systems. In fact, as 
the notion of stallable system and patient system correspond respectively to the 
notion of stuttering-invariant system and endochronous system. Corollary 1 sub- 
sumes the result presented in [10] on the compositionality of latency-insensitivity 
among patient processes. 

Now, the remaining key challenge is to make the theory of this paper effective. 
In this respect. Theorem 1 and its corollary are not enough, since they involve 
(infinite) behaviours. What is needed is sort of a counterpart of “automata” 
for our Tagged Systems. Synchronous Transition Systems as used in [6] are an 
example. Order automata are another example, that can be associated to Tagged 
Systems with causality relations. How to define such machines for general Tagged 
Systems is our next objective. Then, having this at hand, we will have to properly 
extend the “endochrony” and “isochrony” results of [6] , thus providing effective 
algorithms to generate adaptors that ensure correct-by-construction deployment 
for general Tagged Systems. 
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Abstract. Machine functions have been introduced by Earley and Stur- 
gis in [6] in order to provide a mathematical foundation of the use of the 
T-diagrams proposed by Bratman in [5] . Machine functions describe the 
operation of a machine at a very abstract level. A theory of hardware and 
software based on machine functions may be called a machine function 
theory, or alternatively when focusing on inputs and outputs for machine 
functions a control code algebra (GCA). In this paper we develop some 
control code algebras from first principles. Machine function types are 
designed specifically for various application such as program compilation, 
assembly, interpretation, managed interpretation and just-in-time com- 
pilation. Machine function dependent GCA’s are used to formalize the 
well-known compiler fixed point, the managed execution of JIT compiled 
text and the concept of a verifying compiler. 



1 Introduction 

Machine models can be given at a very high level of abstraction by using so- 
called machine functions, a concept due to [6] as a basis. Machine functions 
are hypothetical functions, which may be classified by machine function types. 
Machine function types provide information about the expected inputs and out- 
puts, or more general the behavior of a machine. Machine functions are named 
elements of machine function types. Machine functions are used as the primitive 
operators of a control code algebra. Machine functions may be viewed as black 
box containers of behavior. It is not expected that machine functions are actu- 
ally either formally specified or algorithmically given in any detail. Important, 
however is the realization that different machine architectures may use different 
machine functions as realizations of the same machine function type. A number 
of issues is can be clarified using machine functions only: the so-called compiler 
fixed point, the distinction between compilation and interpretation, the role of 
intermediate code, managed execution and JIT compilation, and finally verifying 
compilation. 

1.1 Motivation 

The identification of machine function types and the description of machine 
models as composed from named but otherwise unspecified machine functions 
may be helpful for the following reasons: 
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~ A multitude of different machine models and instantiations thereof can be 
described in some formal detail while at the same time ignoring the massive 
complexities of processor architecture and program execution. 

— Machine function theory can be used to obtain logically complete machine 
models. A machine model is logically complete if all of its concepts are ex- 
plained in internal technical terms in a bottom up fashion, permitting a 
reader to understand the model and stories about it without the use of sub- 
ject related external knowledge and without understanding in advance the 
whole story of modern computer architecture. 

— By giving names to machine functions simple calculations are made possible 
which may produce insights unavailable otherwise. In addition system spec- 
ifications can be given in terms of combinations of requirements on a family 
of named machine functions. Machine function theory is a very elementary 
ax;iomatic theory of machine behavior, not claiming that the essential prop- 
erties of machine functions are captured by ax;ioms. The more limited claim, 
however, is that the role that machine functions play in a larger architectural 
framework can be analyzed in some useful detail. 

— Pseudo-empirical semantics explains the meaning of codes and concepts re- 
garding codes by means of hypothetical experiments with the relevant ma- 
chine functions. The phrase ‘the meaning of a code is given via its compiler’ 
belongs to the dogma’s of pseudo-empirical semantics. Pseudo-empirical se- 
mantics provides definitions close to what computer users without a back- 
ground in formal semantics may have in mind when working with machines. 



1.2 Control Code Algebras 

Each machine function gives rise to an algebra with codes as its domain. Codes 
are represented as finite sequences of bits. The codes play the role of input data 
and output data as well as of control codes. As the main focus of the use of 
machine functions is in analyzing semantic generalities of control codes at a 
very abstract level these algebras will be referred to as control code algebras 
(CCA’s).^ Control code algebra (CCA) is the meta theory of the control code 
algebras. It might just as well be called machine function theory. 

1.3 Scope of CCA 

The simplest CCA may be viewed as another form of theory of T-diagrams from 
[5], and implicitly present in [7], which has been further developed in [6]. Similar 
work appeared in [1]. Clearly the limits of CCA are reached when modeling a 
phenomenon requires significant information concerning the details of machine 
code execution at the lowest level of abstraction. An extreme view might be that 
each insight in computer software processing which is independent of the details 



^ The acronym CCA is a mere abbreviation, having well over a million hits on Google 
and in no way specific. Its expansion ‘Control Code Algebra’ generates no single hit, 
however, at the time of this writing. 
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of code may lie within the scope of CCA. Here are some interesting issues for 
which that is unclear: 

~ Can the phenomenon of computer viruses can be modeled at the level of 
CCA. Many computer users are supposed to use their computers in such a 
way that infections are prevented, while no plausible argument can be given 
that these users must understand the details of how a machine works. The 
question may therefore be rephrased as follows: can an explanation via an 
appropriate CCA be given of what machine users must do in order to prevent 
virus infections of their systems. And, moreover can it be formulated what 
requirements systems must satisfy if these prescriptions for user behavior are 
to guarantee that systems remain clear of infections. 

— Another question that may be answered at the level of an appropriate CCA 
is what an operating system is. Textbooks on operating systems never intro- 
duce the concept of an operating system as a concept that merits a definition 
in advance. Substantial questions concerning what minimum might be called 
an OS and whether or not an OS is a computer program or a control code 
are impossible to answer without proper definitions, however. 

— A third question which may or may not lie within the scope of CCA is the 
question as to what constitutes a software component. By its nature the 
concept of a software component abstracts from the details of computation. 
But a first attempt to define software components in the framework of CCA 
reveals that some non-algorithmic knowledge about software component in- 
ternals may be essential and outside the scope of CCA at the same time. 



2 External Functionality Machine Functions 

A way to capture the behavior of a machine is to assume that it has a simple 
input output behavior, taking an number of bit sequences as its an put and 
producing similar outputs. Taking multiple inputs into account is a significant 
notational overhead but it will be indispensable for instance when discussing 
the notion of an interpreter (for the case of multiple inputs) whereas multiple 
outputs arise with a compiler that may produce a list of warnings in addition 
to its compilation result. A list (with length fc > 0) of bit sequences (codes) is 
taken as an input and the result takes the form of one or more bit sequences. If / 
is the name of a machine function and n is a natural number then /„ names the 
mapping that yields the n-th result. The result of / on an input list y may be 
undefined (M, for meaningless) or divergent {D). In case of divergence none of 
the outputs gets computed, in the case of convergence from some index onwards 
all outputs are M, indicating that it has not been provided. The following axioms 
are imposed: 

Vn, m ifn{y) = D ^ fm{y) = D) 

Wn,m{fn{y) = M km > n ^ fm{y) = M) 

Vn(/„(y) ^ D ^3m> nfjn{y) = M) 
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Vn {fn{y '^'z) = M ^ f^{y) = M) 

Vn(/„(y) = D ^ fm{y'~'z) = D) 

These rules express that 

— The sequence of outputs is computed in a single computation. A divergence 
implies that no bit sequences can be produced, whereas an error (M) only 
indicates that a certain output is not produced. Only finitely many outputs 
bit sequences are produced, and beyond that number an error occurs. 

— There is one algorithm doing the computation accessing more arguments 
when needed. When arguments are lacking an error (M) will occur, rather 
than D. Providing more inputs {y'~z instead of y) cannot cause an error 
(M). In other words if a computation on a list of inputs runs into an error 
than each computation on a shorter list must run into an error as well. 

~ A divergence taking place on a given sequence of inputs cannot be prevented 
by supplying more inputs. (This in contrast with an error which may result 
from a lack of inputs.) 

2.1 External Functionality 

A machine function produces external functionality if the transformations it 
achieves are directly contributing to what users intend to do. A typical example 
may be a formatting/typesetting functionality. Often user commands directly 
invoke the operation of an external functionality. 

External functionality machine functions describe external functionalities. 
Their operation can (but need not) be exclusively under the control of manu- 
ally entered user commands. Here is a somewhat artificial example involving a 
compiler and a cross-assembler producing executable code for another machine. 
Because the produced code must be moved elsewhere before use, its machine 
may be regarded external functionality. 

Using Bit Sequence Machine Functions, an Example. One may imagine 
a machine P powered by the, bit sequence machine function Fc, requiring one 
input and producing three outputs for each input, and the bit sequence machine 
function Fd also requiring a single input and producing 2 outputs in all cases. 
The inputs are taken from a stack, the first input from the top and so on, while 
the outputs are placed on the stack in reversed order, after removing the inputs. 

For instance Fc takes a program in and compiles it in the context of a list of 
programs (encoded in the second argument), producing the output code, a listing 
with error messages and warnings and an assembled version of the compiled code. 
Fd applies a disassembler to its first argument producing the result as well as a 
listing of errors and/or warnings. 

A manual operation of the system is assumed with the following instructions: 
s . load : /, pushing file / on the stack and s . store : g, placing the top of the stack 
in file g while subsequently popping the stack. Here s stands for the machine 
command interface able to accept and process manual user commands. s.Fc is 
the command that invokes the operation of the first of the two machine functions 
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and produces three output sequences that are placed on top of the stack. s.Fd 
is the command for the second one, which places two results on the top of the 
stack consecutively. How such commands are entered is left unspecified in the 
model at hand. 

Consider the command sequence 

CS = s . load: f ; s .Fc ; s . store : g; s .pop; 

s .pop ; s . load: g; s . Fd; s . store :h; s .pop 

If the content of f before operation is x then after performing C S the content 
of h is Fdi{Fc\{x)) . This output is probably empty if either one of the two 
commands lead to error messages, whereas if the error message output is empty 
on may assume that the other outputs are ‘correct’. It also follows from this 
model that the operation of the system is deterministic for command sequences of 
this kind. Several potentially relevant system properties may now be formulated: 

Code is produced unless errors are found Fc2{x) = [] ^ Fci{x) yf [] 
Disassembly succeeds unless errors are found Fd2{x) = [] ^ Fi{x) yf [] 
Disassembly inverts of assembly Fc2{x) = [] ^ Fdi{Fc3{x)) = Fci{x) 

The use of machine functions in the examples mentioned above is in making 
these requirement descriptions more readable than it would be possible without 
them. With these few primitives there appears to be no significant reasoning 
involving calculation, however. 

Non-programmable Machines. If a machine is given by means of a finite 
list of machine functions one may imagine its user to be able to enter inputs, 
select a function to be applied and to retrieve outputs thereafter. We will not 
provide syntax or notation for the description of these activities. As it stands a 
non-programmable machine may be given in terms of finite listing of machine 
functions. As the number of machine functions of a machine increases it becomes 
increasingly useful to represent machine functions as codes and to use a single 
universal machine function from which the other machine functions are derived. 
In this way a control code dependent machine emerges. This universal machine 
function is used to bring other codes into expression. Therefore the phrase code 
expression machine functions will be used rather than the term universal machine 
function, which is somewhat unclear regarding to the scope of its universality. 



3 Code Expression Machine Functions 

It is now assumed that the first argument of a machine function consists of a bit 
sequence which is viewed as control code for a machine. Through the application 
of the machine function the control code finds its expression. Formally there is 
no difference with the case of an external functionality machine function. But the 
idea is that without a useful control code (i.e. a first argument for the machine 
function) no significant external functionality may be observed. It is a reasonable 
assumption for a simplest model that a machine which can be controlled via 
exchangeable data must be controlled that way. At this stage the important 
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question what makes a bit sequence a control code (rather than just its place in 
the argument listing of a machine function) is left for later discussion. 

For code expression machine functions another notation is introduced which 
separates the first and other arguments. A notation for the n’th result of a 
code expression function taking k arguments (except the code argument x) is as 
follows: 

X • •"'yi,..,yk 

By default the first argument is meant of no superscript is given: 

X • •yi, -,yk = x» •^ 7 / 1 , ,.,yk 

If the name / is given this can be made explicit with x • ujyi, ..,yk- The 
semantics of a control code x w.r.t. a machine function is the family of all 
machine functions taking x fixed, denoted |a;|„. Thus semantic equivalence for 
control codes reads 

X =beh z ^ |x|„ = |z|„ ^ Vn, k, 7 / 1 , .., yk{x • *"7/1, .., yk = z • *”7/1, .., yk). 

With an explicit name of the machine function this reads: 

X =beh z ^ ^ \/n,k,yi, ..,yk{x • •jT/i, ,.,yk = 2 • •/j/i, .., 7 /fc). 

Bit sequence generating machine functions are less useful when it comes to 
the description of interactive systems. But code expression machine functions 
are very simple as a concept and they can be used until a lack of expressive 
power or flexibility forces one to move to a different model. ^ 

3.1 Split Control Code Machine Models 

A code expression machine function — • • y — determines all by itself a machine 
model. For an execution, which takes a single step, a triple of the code and a 
sequence of inputs and the machine function are needed. This may be formalized 
as mf{x,y). The code is not integrated in the machine in any way. Thus it is 



^ The discussion may be made more general by using a terminology consistent with 
the possibility that a machine function produces an interactive behavior (i.e. a pro- 
cess). A bit sequence generating machine function is just a very simple example of a 
behavior. If the behavior of a machine is described in terms of a polarized process its 
working may be determined through a function that produces a rational polarized 
behavior over a given collection A of basic actions from the codes that have been 
placed in the machine as an input or as a control code. The reason to consider a 
mapping function, say Fm '■ BS x BS x BS BPPA{A), as the description of a 
machine if a control code dependent machine is to be compared with a programmable 
machine. BPPA is the algebra of basic polarized process from [2]. As will become 
clear below polarized processes are well-suited for the specification of programs and 
programmed machine behavior. In the case such a machine needs to be viewed as a 
control code dependent machine a polarized process machine function results. 




Machine Function Based Control Code Algebras 



23 



implausible to speak of a stored code. For that reason the model is classified 
as a split control code machine model. This is in contrast with a stored code 
machine model for which it is required that code storage is achieved by means of 
the same mechanisms as any storage during computation. As nothing is known 
about these mechanisms due to the abstract nature of machine functions, being 
no more than formal inhabitants of their types, the model cannot be classified 
as a stored control model. 

Having available the notion of a split control code machine, it is possible 
to characterize when a code is an executable for it: x is an executable for •• f 
if for some y, x • •fy ^ M. Because this criterion depends on an application 
of the code in an execution it is a dynamic criterion. In practice that may be 
useless and entirely undecidable. For that reason a subset (or predicate) Ec of the 
executables may be put forward as the collection of ‘certified’ executables. Here 
it is understood that certification can be checked efficiently. A pair is 

a split control machine with certified executables. 

It is always more or less taken for granted that modern computer program- 
ming is based on the so-called stored program computer model. In the opinion 
of the author a bottom up development of the concept of a program starts with 
a split program machine model, however, the register machine constituting a 
prime example of a split program machine model. Having available a split pro- 
gram machine model one may then carry on to develop stored program machine 
models. The usual objection against this argument is that a Turing machine ([9]) 
constitutes a stored program machine model already. That, however, is debat- 
able because it is not clear which part of the tape content or state space of a 
Turing might be called a program on compelling grounds. Usually some intuition 
from an implicit split machine model is used to provide the suggestion that a 
part of the tape contains a program in encoded form. That, however, fails to be 
a compelling argument for it being a program. 

3.2 Two Conceptual Issues on Split Code Machine Models 

The split control code machine model aims at providing a very simple account of 
control code dependent machines while ignoring the aspect of the control code 
being either a program or being cast in software. There are two philosophical 
issues that immediately emerge from the introduction of the concept of a split 
control code machine. 

The Control Code Identification Problem. An explanation is needed for 
why the first code argument is said to contain the control code. It seems to be a 
rather arbitrary choice to declare the first argument the control code argument 
rather than for instance the second argument. This is the control code iden- 
tification problem for an external machine function. The question is about the 
machine function and irrespective of any of its actual arguments. So the problem 
is: determine, given a code expression machine function, which of its argument 
contains the control code if any. 
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Below in 5.2 we will see that the situation is not symmetric indeed and sound 
reasons may exist for taking one code argument to play the role of containing 
the control code rather than another argument.^ 

The Program Recognition Problem. An obvious question raised by the split 
control code machine model is this: under which circumstances is it appropriate 
to view an executable control code as a program? This is the program recognition 
problem. It presumes that the control code identification has successfully led to 
the classification of an argument position as the (unique) position for control 
code. This question is important for an appreciation of the distinction between 
control code an programs. This question can be answered first by means of the 
hypothetical program explanation principle which has been proposed in [3]. 



4 Split Program Machine Models 

Complementary to split control code machine models there are split program 
machine models. For the development of CCA it is in fact immaterial how the 
concept of a program is defined. What matters is that for some code to be called 
a program some definition of what it is to be a program is needed. Let some 
theory of programming be given which provides one with a reliable definition of 
the concept of a program. 

A split code machine model (i.e. a code expression machine function) quali- 
fies as a split program machine model if there is for each code a mapping to an 
acknowledged program notation (which may be hypothetical) for a (hypotheti- 
cal) machine model such that the machine function describes the behavior of the 
(hypothetical) machine as programmed by a code (viewed as a program). Thus 
each code may be read as a program for a machine with a well-understood op- 
erational meaning which produces results that happen to coincide with those of 
the given machine function. In other words the code expression machine function 
is an abstraction of a split program machine model. 

As a notation for a split program machine model with name / we take 

X ••spm- fVu-^yk 

The semantics of a program w in a split program machine model is derived in 
a completely similar style to the split control code case with notation 

A split program machine model will also called an analytical architecture 
because it focuses on the analysis and explanation of behavior, whereas a split 
control code machine model may be called a synthetic architecture because it 
focuses on the components from which the machine is physically synthesized, 
without any commitment to the explanation of behavior. 



® When investigating stored control code machines or stored program machines this 
question reappears in the following form: which memory compartment contains con- 
trol code or program code? 
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4.1 Hypothetical Architectures and Program Recognition 

For this section it will be assumed that a split program machine is like a split 
control code machine with the additional information that the control code con- 
stitutes a program irrespective of the definition of a program that has been used. 
Further it is assumed that the behavior for a split program machine can be found 
in such a way that the program helps to understand the code expression machine 
function (or process machine) function at hand. That is to say, the split program 
machine is considered more easily understood or explained because its program 
and the working of that program is known and it is also known how the program 
is transformed into the produced behavior by means of interaction with other 
relevant parts of the machine. 

A control code is just data without any indication that it has the logical 
structure of a program. 

Having available the concept of a split control code machine model one may 
then investigate under which conditions a split control code may appropriately 
be called a control code and even a program. This is the program recognition 
that was problem mentioned above. 

The Program Recognition Problem: An Informal Solution. A code is a 
program if it can be viewed as the product of some computable transformation 
translating (machine) programs for some conceivable programmable architecture 
to code for a split code machine. This state of affairs indicates that the reasons 
for classifying code as a program lie in the possibility of reverse engineering, or 
rather disassembling, the code into a program for some programmable machine, 
which may serve as an explanation for the given code. 

The Program Recognition Problem: A Formalized Solution. Given the 
split control code machine •• / and a collection R of relevant functionalities for 
•• /, a control code a; is a program if there exists a split program machine rnodel"^ 
••spm-g and a computable code generation mapping^ tp^2f from programs for 
••spm-g to codes for •• f such that 

— Hypothetical program existence: x is in the range of ip (e.g. for some z, 

X = 1pg2i{z)), 

~ Hypothetical assembler soundness: for all programs u (for ••spm-g) 
|V'g2f(u)|..,p„_j = and: 

— Functional assembler completeness: for all control codes x for ••/: if the 
behavior 1 ^ 1 , belongs to the collection R, which covers the relevant func- 
tionalities for which the machine model has been designed, then either 

• u has a disassembled version {z with ipg2i{z) = x)) (which qualifies as 
a program for the split program model architecture providing the same 
functionality), or otherwise. 



^ The hypothetical programmed machine architecture. 

® Also called assembler mapping, the inverse being an assembly projection. 
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• there is a program z such that and consequently 

This last condition guarantees that the split program machine has not been 
concocted specifically to turn the particular control code x into a program (ac- 
cording to our proposed definition) but instead that this hypothetical machine 
provides an explanation of the full operational range of •• / by providing a pro- 
gram for each relevant behavior. 

4.2 Control Code Need Not Originate Through Programming 

One may wonder whether split control code is in all cases a transformation prod- 
uct of programs. If that were true the conceptual distinction between programs 
and code is marginal, a matter of phase in the software life-cycle only, and as a 
consequence the concept of control code is only seemingly independent of that 
of a program. We give two examples of control code that fails to qualify as a 
program. The conclusion is drawn that there are (at least) two entirely different 
strategies for computer software engineering, only one of which involves pro- 
gramming. Machine functions provides an abstraction level that both strategies 
have in common. 

Two Examples of Non-programmed Control Code. A counterexample to 
the hypothesis that all control code originates as the result of program produc- 
tion may be as follows: one imagines a neural network in hardware form, able to 
learn while working on a problem thereby defining parameter values for many fir- 
ing thresholds for artificial neurons. Then the parameter values are downloaded 
to a file. Such a file can be independently loaded on a machine, depending on 
the particular problem it needs to address. These problem dependent parameter 
files can be considered control code by all means. In all likelihood they are not 
programs in any sense supported by our theory of programming, however. The 
particular property of neural networks is their ability to acquire control code 
along another path than human based computer programming. 

Another example of control code which may rather not be understood as a 
program is the geographical information downloaded in a purely hardware made 
robot together with a target location it is supposed to find. The robot will apply 
its fixed processing method to these data, but the data determine the behavior of 
the robot. The loaded data constitute control code (this follows from the absence 
of other software in the robot). But programming (compliant with the assumed 
theory of computer programming) has played no role in the construction of this 
control code. 

In both mentioned examples of control code which is not the result of pro- 
gram transformation artificial intelligence plays a role. In the case of the neural 
network the learning process itself is an example of artificial intelligence, whereas 
in the case of the robot the processing performed by the robot must involve sig- 
nificant AI applications. In the robot case the preparation of control code is 
similar to the briefing a human being might get when confronted with the same 
task. 
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Two Software Engineering Strategies. Machine learning may altogether 
be understood as an alternative form of control code production, contrasting 
with the currently more usual control code development starting with computer 
programming and followed by compilation and assembly phases. 

Examples of non-programming based software engineering outside artificial 
intelligence seem to be hard to find. Both examples above embody different 
aspects of artificial intelligence based software engineering: control code con- 
struction by means of artificial intelligence and control code construction for 
an artificially intelligent system play a role in non-programming based software 
engineering. Therefore software engineering is in terms of software construction 
techniques covered strictly larger than computer programming, as it also covers 
these AI based techniques. 

A Third Option: Genetic Control Code Evolution. A third option for 
software engineering that may avoid programming as well as neural network 
training lies in the application of genetic algorithms. This involves a number of 
operators for constructing new control codes from (pairs of) known ones. Then 
by randomly applying these operations on some initial codes and by filtering out 
codes that are bad solutions for the software engineering problem at hand an 
evolutionary process may produce adequate solutions. 



5 The Code Identification Problem 

The essential simplification of split control code in comparison to split programs 
lies in the decision to view code as binary data without any need to explain why 
these data play the role of programs or may be best understood as programs. 
This, however, leaves open the question as to why a certain code is classified as 
a control code. 

5.1 Splitting Control Code from Inputs 

Given a split control code machine, one may take its first argument as just one 
of the arguments, thus obtaining a code expression machine function. Looking at 
the split control code machine from this level of abstraction, a question similar 
to the program recognition problem appears: why has the first of the arguments 
been split of to play the role of the control code. The notion of overruling is now 
proposed to deal with this issue. 

Symmetry Prevents Control Code Identification. It is useful to experi- 
ment for a while with one simple design for the split control code machine, by 
assuming that there is just a single input. In particular consider the split control 
code machine •• f . By forgetting the control code role of the first argument a 
control code independent machine is found (say Sf) and its behavior is given by 
Sf{x, y) = X • •fy The only possible justification for making the first argument 
play the role of a control code and the second code argument the role of an 
input code must lie in properties of the code expression machine function Sf. 
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Indeed suppose, hypothetically that for all x and y, Sf{x,y) = Sf{y,x). Then 
the symmetry is complete and a justification for putting the first argument of 
S f in the role of control code and the other argument in the role of input data 
cannot be found. 

A justification for putting the first argument in the control code role can only 
be found if the code expression machine function is asymmetric and if, moreover, 
the first code argument (x) can be said to be ‘more in control’ than the second 
one (y) or any other argument. The control code identification problem will now 
be simplified to the case that the code expression machine function has exactly 
two inputs. The task is to select the control code input, if that can be done. 
Here are three informal criteria that may be applied to argue that indeed, the 
first argument has the role of a control code: 

Overruling Argument Positions. For a two place function F : BS x BS 
BS U {Z?,M} the first argument overrules the second if there can be found 
different sequences e.g. 0 \ = ”0” and O2 = ”1” and codes x\ and X2 such that 
for all code arguments y, F{x\,y) = 0 \ and F{x2,y) = O2. 

If the first argument overrules the second, the second one cannot overrule 
the first argument at the same time. Indeed suppose that O3 yf O4 and that j/3 
and 2/4 are found such that for all x, F{x,y^) = O3 and F{x,y4) = O4. Then 
it follows that O3 = F(xi,y3) = Oi = F(xi,y4) = O4, which contradicts the 
assumptions. 

5.2 Control Code Overrules Non-control Code 

Consider Sf{x,Y), then the first argument is said to be at the control code 
position (for Sf) if the first argument overrules the second argument. If this 
condition is met that condition solves the control code identification problem 
and justifies the notation x • ujy = Sf{x,y). 

The criterion of overruling becomes more interesting if there are more than 
two code arguments needed to have a successful (not yielding M) computation 
of the split control code function. Below the concept of a split interpreter con- 
trol machine model will be outlined. In the case of split interpreter control two 
argument positions have great influence on machine operation: the control code 
position where the interpreter control code is located and the position where the 
code to be interpreted is located. In this setting the first position overrules the 
second position and the second position overrules the third position. But the 
dependence of behavior from the second argument is more flexible than for the 
first argument. 



6 Control Code Assembly Notations 

In the sequel the assumption is made that for the class of split control code 
machines of interest all control codes are actually transformed programs in the 
sense of 4.1. This assumption justifies the jargon used. 
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6.1 Executables 

Given a split control code machine the control codes may as well be called exe- 
cutables. This phrase is often used if control codes are transformed programs. It 
is common to make a distinction, however, between arbitrary control codes and 
executable control codes, or simply ‘executables’ where executables are those 
control codes really meant for execution on the model. Lacking any intrinsic 
criterion as to which codes are to be considered executable it is reasonable to 
assume that some collection Ec of codes comprises the executables. This collec- 
tion is specific to the code expression machine function of the machine model 
under consideration. 

6.2 Assembly and Executable 

One may consider the notion of an assembly notation for a given split control 
code machine with certified executables Ec- An assembly code should be a useful 
tool for a human author in the production of control code. It allows the produc- 
tion of readable and meaningful texts which may be automatically transformed 
into control codes by means of an assembler which is given in the form of an- 
other control code. In this discussion the question who wrote the assembler and 
how this may have been done without the help of an appropriate design code is 
ignored. The simplest view is that producing the assembler in the absence of a 
suitable control code design notation has been an enormous amount of work that 
may be seen as a part of the investment of the development of a split control 
code machine, which is useless otherwise. 

A control code assembly notation (say A) is simply viewed as a subset of the 
possible codes. An assembler for A is an executable control code n:a2e:e. Here 
the colon is part of the name, which thereby carries the following information: 
code reference n including a version number, functionality a2e (from assembly 
to executable) and code class e (for executable) . The assembler must satisfy this 
criterion: for each code x:a G A, n:a2e:e**x:a G E^. Thus, a compiler transforms 
each control code design into an executable.® 

6.3 Assembling an Assembler in Assembly 

An interesting thought experiment now runs as follows. Let an assembler xl:a2e:e 
for A be given. Assume that a version of an assembler for a is made available, 
written in the assembly notation A represented by a itself.^ The following name 
will be used for this new version of the compiler: u:a2e:a. The name combines a 
local name (rt), a functionality (o2e) and a notation that is used (A). The new 
assembler cannot be used without preparatory steps. It needs to be assembled 



° It is a common additional requirement that for codes outside A a non-executable 
output is produced together with a second output which contains a list of so-called 
errors allowing the control code designer to find out what is wrong. 

This is not implausible as the compiler is a complex piece of control code which may 
profit from advanced design technology. 
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itself by means of the existing assembler which is available in an executable form 
already. With that in mind first of all the correctness of this new assembler can 
be formalized as follows: 

(1) It can be assembled successfully by means of the given assembler i.e., 

xl : o2e : e • •w. a2e : a € Ec, which permits one to write x2 : a2e : e for 
xl:a2e:e • •u:a2e:a. 

(2) x2:a2e:e is a control code that transforms each a code into an executable. 

(3) For all control code designs y.a the two executable assemblers mentioned in 
(2) produce equivalent control executables. That is, 

|a;l:a2e:e • = |a;2:a2e:e • •y:a\„. 

Assembling an Assembler Once More. Now the following well-known ques- 
tion can be raised: is it useful to use a;2:a2e:e to assemble the code u:a2e:a once 
more? Let x3:a2e:e = x2:a2e:e • •u:a2e:a. This must be an executable because 
a;2:o2e:e is an assembler for A. Due to the assumption that x2:a2e:e is a correct 
compiler this second new assembler must also be a correct one because it deter- 
mines a semantics preserving code transformation, i.e x3:a2e:e =behavior x2:a2e:e, 
or equivalently: |a:3:a2e:e|„ = |x2:a2e:e|„. 

Why may it be an advantage to make this second step? The second step takes 
the new executable assembler (obtained after assembling with the old one) to 
assemble the new non-executable. A useful criterion here is code compactness, 
measuring the length of control codes. Now suppose that the new assembler 
produces much shorter code than the old one, then the second step is useful to 
obtain a more code compact executable for the new assembler. The executable 
version of the new assembler x2:a2e:e has already the virtue of producing short 
codes but its own code may still be ‘long’ because it was produced by the old 
assembler. 

The Assembler Fixed Point. The obvious next question is whether it is useful 
to repeat this step once more, i.e. to use x3:a2e:e once more to assemble the new 
assembler. It is now easy to prove that this will bring no advantage, because it 
will produce exactly the code of x3:a2e:e. This is the so-called compiler fixed 
point phenomenon (but phrased in terms of an assembler). In more detail, let 
a;4:a2e:e = x3:a2e:e • •u:a2e:a. Because |x3:a2e:e|„ = |a:2:a2e:e|,,, which has 
been concluded above, a;3:o2e:e • •u:a2e:a = x2:a2e:e • •u:a2e:a = x3:a2e:e. 

This leads to the following conclusion: if a new assembler is brought in for a 
notation for which a assembler in an executable form is available and if the new 
code is written in the assembly notation itself then it is necessary to translate 
the new assembler with the old executable assembler first. Thereafter it may be 
an advantage to do this once more with the executable assembler just obtained. 
Repeating this step a second time is never needed. This is a non-trivial folk-lore 
insight in systems administration/software configuration theory. It exists exactly 
at the level of abstraction of machine functions. 

The Assembler Application Notation. The machine function of an assem- 
bler code merits its own notation: x:a • •aV-d = {xl:a2e:e • ux'-a) • •y.d. 
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Using this notation the versions of the executable code that occur in the 
description of the fixed point are: x3 : o2e : e = u: a2e : a • *aU : a2e : a, and 
a:4:a2e:e = {u:a2e:a • •aU:a2e:a) • •u:a2e:a (= x3:a2e:e • •u:a2e:a). The fixed point 
fact itself reads: {u:a2e:a • •au:a2e:a) • •u:a2e:a = u:a2e:a • •au:a2e:a. 

Correct Assembly Code. An assembly code is correct if its image under the 
assembler is an executable, thus z G ii xl:a2e:e • *z G The correct 
codes depend on the available assembler codes. Improved assemblers may accept 
(turn into an executable) more codes, however, thereby increasing the extension 
of ‘correct assembly codes’. 

7 More Dedicated Codes 

It is reasonable to postulate the availability of an executable code which allows 
to test the certified executability of codes. Let al : Me : e be the application 
code a testing for executability (functionality Me) in executable form. Then 
al:Me:e* •w.d produces an empty file on input u:d (data file u which may or may 
not admit the stronger typing u:e) if u:d is a certified executable (i.e. G Ec), and 
a non-empty result e.g. containing a listing of warnings or mistakes otherwise. 

7.1 Source Level Code 

A code notation for source level code S may be modeled as a collection of 
bit sequences. Its codes are denoted e.g. with x:s. A special notation for the 
application of a source level code is useful. The action of source level code on a 
sequence of inputs y is given by x:s • UsV- Given a compiler u:s2a:a for S this 
can be defined by: x:s • »sy = {u:s2a:a • •aX:s) • *ay. 

It is assumed that u:s2a:a • •aX'.s never produces D and that the first output 
is a correct assembler code provided the second result {u:s2a:a • •1,x:s) is the 
empty sequence. The correct S codes® are denoted with Sc- 

Compiling a ‘New’ Compiler. Given a compiler Ml:s2a:a for S a new compiler 
u:s2a:s for S written in S may be provided. Then to make this new compiler 
effective it should itself be compiled first and subsequently be used to compile 
itself. Then the compiler fixed point is found entirely similar to the case of the 
assembler fixed point mentioned before. The new compiler may be compiled into 
assembly: u2:s2a:a = ul:s2a:au •aU:a2e:s. It is then required that for all y:s G Sc, 
\ul\s2a\a • •ay'-s\,,^ = \u2:s2a:a • •ay-s\,,^. 

The Compiler Fixed Point. The next phases are given using source level 
application notation: x:su •sy-d = {ul:s2a:au •ax:s) • •ay-d. Using this notation 
the versions of the assembler code that occur in the description of the fixed point 
are: u3:s2a:a = u:s2a:s • •su:s2a:s, and x4:o2e:e = {u:a2e:a • •aU\a2e:a) • •u:a2e:a. 
The fixed point fact itself reads: (u:s2a:s»*sU:s2a:s)**M:s2a:s = u:s2a-.s»»sU\s2a-.s. 



® Ac may be called the pseudo-empirical syntax of A. 
® Compiler based pseudo-empirical syntax of S. 
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7.2 Interpreted Intermediate Code 

Taking three or more inputs and two outputs it becomes possible to view the first 
input as the control code for an interpreter, the second input as a control code to 
be interpreted and the third input (and further inputs) as an ordinary argument, 
while the first output serves as the standard output and the second output serves 
as error message listing when needed. In actual computer technology compilation 
and interpretation are not alternatives for the same codes. A plausible setting 
uses an interpreted intermediate code notation I Correct intermediate codes 
must be defined via some form of external criterion. Thus 1^ may be the collection 
of certified intermediate codes. The functionality of interpreters for I is denoted 
intAi, an interpreter for / is an executable w.intAi:e. The application of / code 
is then defined as x:i • •mtuV = u:int4i:e • »x:i '~ y. 

Compiling to Interpreted Code. A compiler from source code notation S 
to / is an executable u:s2i:e. Having available a compiler to I an alternative 
definition of the correct codes for S is given by: x G Sc-int if and only if u:s2i: 
e • G /c-^° 

In the presence of a compiler for S' to / as well as to A (which has a definitional 
status for S by assumption) the following correctness criterion emerges: (i) for 
all x:s G Sc n Sciint, and for all data files y: x:s • Usy = {u:s2i:e • •x:s) • •intay 
and (ii) Sc C Sc-.m- 

It is also possible that S is primarily defined in terms of its projection to I . 
Then the second condition becomes Sc A Sc-.int, thus expressing that the com- 
piler which now lacks a definitional status can support all required processing. 

7.3 Managed Execution of Compiled Intermediate Code 

The intermediate code is managed (executed in a managed way) if it is both 
assembled and compiled. Thus an interpreter, vm called a run-time (system) 
vm : rtAae : e acts as an interpreter for a compiled version of the intermediate 
code. rtAae is the role of run-time for an almost executable code. This code is 
also called a virtual machine, which has been reflected in its mnemonic name. The 
intermediate code is compiled by c:i2ae:e to a stage between the assembly level 
and the executable level denoted AE. This leads to the definition x:i • •i-.my = 
vm:rt4ae:e • •{c.i2ae:e • ux'd) '~'y. 

Managed code execution allows the virtual machine to perform activities like 
garbage collection in a pragmatic way, not too often and not too late, depending 
on statistics regarding the actual machine. Other activities may involve various 
forms of load balancing in a multi-processor system. Also various security checks 
may be incorporated in managed execution. 

JIT Compiled Intermediate Code. At this stage it is possible to indicate 
in informal terms what is actually supposed to happen in a modern computer 
system. Source codes are compiled to an intermediate code format. That code 



Interpreter based pseudo-empirical syntax for S. 
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format is assumed to be widely known thus permitting execution on a large 
range of machines. Its execution involves managed execution after compilation. 
However, compilation is performed in a modular and fashion and the run-time 
system calls the compiler which then compiles only parts of the intermediate code 
when needed, throwing the resulting codes away when not immediately needed 
anymore, and recompiling again when needed again. This is called ‘just in time 
compilation’ (or JITting for short). The use of JIT compiler based managed 
execution has the following advantages: 

(i) The accumulation of a machine specific (or rather a machine architecture 
specific) code base is avoided, in favor of a code base consisting of intermediate 
code which can be processed on many different machine architectures. Espe- 
cially if the code is very big and during an execution only a small fraction of it 
is actually executed integral compilation before execution becomes unfeasible. 
Therefore mere code size implies that a decision to design an intermediate code 
for compilation forces one to opt for JIT compilation. 

(ii) The advantages of managed execution are as mentioned above. Only 
managed execution can provide a high quality garbage collection service, because 
a naive approach where all garbage is removed immediately after its production 
(i.e. becoming garbage) is impractical and inefficient. 

(iii) The advantages of (JIT) compilation in comparison to intermediate code 
interpretation are classical ones. Compiled code execution may be faster than 
code interpretation, and, perhaps more importantly, because the intermediate 
code will be (JIT) compiled, it may be more abstract and therefore shorter, more 
comprehensible and more amenable to maintenance than it would be were it to 
be interpreted. 



8 Machine Functions for JIT Compilation 

The formalization of JIT compilation requires code to consist of parts that can 
be independently compiled. The syntax of multi-part code below will admit 
this aspect of formalization. For the various parts of multi-part code to work 
together intermediate results of a computation need to be maintained. That 
can be modeled by using machine functions that produce a state from a state 
rather than a code from one or more codes. State machine functions (also termed 
state transition functions) will be introduced to enable the formalization of the 
sequential operation of different program parts. Finally program parts may be 
executed several times during a computation in such a way that different entry 
points in the code are used. Natural numbers will be used as code entry points. 

8.1 Multi-part Code 

Code can be extended to code families in various ways. Here we will consider so- 
called ffat multi-part code. A ffat multi-part code is a sequence of codes separated 
by colons such as for instance 10011:1110:0:0001. The collection of these codes 
is denoted with MFC (multi-part codes). It will now be assumed that the input 
of a machine function is a code family. The case dealt with up to now is the 
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special case where multi-part codes have just one part (single part codes: SPC). 
Access to a part can be given via its rank number in the flat multipart code 
listing, starting with 1 for the first part. MPCN, (multi-part code notation) 
admits bit sequences and the associative operator Brackets are admitted 
in MPCN but do not constitute elements of the code families, for instance: 
(10:011):00 = 10:(011:00) = 10:011:00. When multi-part codes are used it is 
practical to modify the type of machine functions in order to admit multi-part 
inputs. 

The n’th part of a multi-part code x is denote part„(x). This notation pro- 
duces empty codes if n is too large. 

Non-separate Assembly and Compilation. An assembler or a compiler for 
multipart code that produces a single executable will be called a non-separate 
assembler or a non-separate compiler. To use a positive jargon a non-separate 
assembler or compiler may be called a gluing assembler or compiler. It is assumed 
that a gluing assembler/compiler detects itself which parts of a code must be 
used, for instance by looking at a code that contains some marker and using some 
form of cross referencing between the parts. Let MPA be a multipart assembly 
code notation. c:mpa2e:e is an executable which transforms multi-part control 
codes to single-part executables. A gluing compiler can be used to define the 
meaning of multi-part control codes as follows: 

x:mpa • •mpaU = {c:mpa2e:e • •x:mpa) • 

Similarly for a notation s, mps may be its multi-part extension. Then one 
may define its meaning given a non-separate compiler by 

x'.mps • •mpsU = (c.mps2a:e • •x:mps) • •aU- 

Separate Compilation. Separate compilation holds for code families of some 
code notation if a compiler ip distributes over the code part separator : ipix'.y) = 
tp(x):'ip{y)). A compiler with this property is called separation modular. So it 
may now be assumed that mS (modular S) consists of sequences of S separated 
by and that u:ms2e:e is a separation modular compiler for mS i.e., using 
MPCN, u:ms2e:e • uy.z = (u:ms2e:e • •y):{u:ms2e:e • »z) for all y and z which 
may themselves be code families recursively. For the second output component 
there is a similar equation: u:ms2e:e • •‘^y.z = {u:ms2e:e • •^y):{u:ms2e:e • 
corresponding equations are assumed for the other output components. 

8.2 State Machine Functions 

Machine functions, as used above, transform sequences of (possibly multi-part) 
input files into output files. This is adequate as long as intermediate stages of 
a computation need not be taken into account. Modeling separate compilation 
typically calls for taking into account intermediate stages of a computation. In 
order to do so we will use state machine functions rather than machine functions. 
State machine functions provide a new state given a control code and a state. 
At the same time it becomes necessary to deal with code entry points. A code 
entry point is a natural number used to indicate where in (the bit sequence 
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of) a code execution is supposed to start. Code entry points will arise if code 
has been produced via imperative programming using a program notation with 
subroutine calls and subsequent compilation and/or assembly. In addition a state 
machine function must produce information concerning which part of the multi- 
part code is to be executed next. It is now assumed that ST denotes the collection 
of states of a machine model. A multipart part code state machine function has 
the following type: 

{SPC X CEP X ST) {{ST U {D, M}) x CPN x CEP) 

Here CPN is the collection of code part numbers and CEP is the the collection 
of code entry points. The CEP argument indicates where in the control code 
execution is supposed to start. These two numbers at the output side indicate 
the code part that must be executed in the next phase of the execution and the 
entry point within that code part which will be used to start the computation 
for the next phase. If the code part number is outside the range of parts of the 
MPC under execution (in particular if it equals 0), the computation terminates, 
and if the exit point is outside the range of exit points of a part termination will 
also result. 

Relating Machine Functions with State Machine Functions. The con- 
nection with machine functions can be given if input files can be explicitly incor- 
porated in the state (using a function ‘in’) and output functions can be extracted 
(by means of ‘out’). State machine functions will be denoted with a single bul- 
let. A CEP argument will be represented as superscript, a CPN argument may 
be given as another superscript, (preceding the CPN superscript), and other 
information may be given in subscripts. For single part code x one may write: 

x:e • •y = out(state(a::e in(y, Sq))). 

Here out produces a sequence of outputs different from M, unless the com- 
putation diverges. This equation provides a definition that works under the as- 
sumptions that the computation starts in state sq and that at the end of the 
single part computation the next part result equals 0: i.e. for some s' and p' , 
x:e»^ (in(y, So))) = (s/0,p'). Moreover it must be noticed that in the notation 
used the separator in the code argument separates name parts for a single part 
code rather than code parts of a multi-part code. 

State Machine Functions for Multi-part Control Code. Assuming that 
multi-part code execution starts by default with the first code part at its first 
entry point the following pair of equations (start equation and progress equation) 
defines the machine function for multi-part executable code (tagged with mpe). 
Start equation: 

x:mpe • »y = out (state (a;:mpe (in(y, so)))) 

expressing that execution starts with the first code part at entry point 1, and 
with the following progress equation: 

paitp{x:mpe) s = {p', q', s') x:mpe s = (s' <1 p' = 0 [> {x:mpe s')) 
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where the progress equation is valid under the assumption that the only returned 
code part number outside the code part range of x:mpe equals 0. 

8.3 Unmanaged JIT 

The JIT equation for (almost) unmanaged^^ multi-part intermediate code exe- 
cution connects the various ingredients to a semantic definition of JIT execution 
for a multi-part intermediate code x:i. The start equation reads 

x:mpi • •jitV = out(state(a::mpt (in(y, Sq)))) 

with the progress equation: 

(c:i2e:e • upaxt p{x:mpi)) •'? s = {p', q' , s') 
x'.mpi s = (s' <1 p' = 0 [> {x'.mpi s')) 

For the progress equation it is assumed that a compiler/ assembler c.i2e:e for 
the intermediate code is available that translates it into executable code. 

Limited Buffering of Compiled Parts. A buffer with the most recent compi- 
lations (i.e. files of the form c.i2e:e • •paxtp{x:i)) of code parts can be maintained 
during the execution of the multi-part intermediate code. Ass this buffer has a 
bounded size, some code fragments will probably have to be deleted during a 
run^^ and may subsequently need to be recompiled. The idea is that a compila- 
tion is done only when absolutely needed, which justifies the phrase JIT. 

8.4 Managed (and Interpreted) Multi-part Code Execution 

Managed code execution involves the interpretation of (JIT) compiled interme- 
diate code. The start equation reads 

x:mpi • •manjity = out(state(a;:TOpz (in(y, sq)))) 

The corresponding progress equation reads 

vm:rt4ae:e in(c:i2ae:e • »partp(a::mpf), s) = (p', g', s') ^ 
x:mpi s = (s' < p' = 0 [> {x:mpi s')) 

The virtual machine vm : rt-iae : e computes the intermediate state reached 
after execution has exited from code part p after incorporating the code to be 
executed in the state. The interpreter takes into account that the code to be 
interpreted has to be started at entry state q. 



The only aspect of execution management is taking care of JIT compiling an inter- 
mediate code part when needed and starting its execution subsequently. 

Code garbage collection. 
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A Requirement Specification for Managed JITting. Provided a compiler 
c:mpi2a:e is known the following identity must hold: 

x:mpi • •manjity = {c.mpi2a\a • •x:mpi) • •aV- 

This equation may be used alternatively as a correctness criterion for the 
definitions using managed JIT compiled execution. The compiler based definition 
will not capture any of the features of execution management but it may be very 
useful as a semantic characterization of the execution of multi-part intermediate 
code. 



9 Verifying Compilers 

Recent work of Hoare (e.g. [4]) has triggered a renewed interest in the idea that 
program verification may be included in the tasks of a compiler. The notion of 
a verifying compiler has been advocated before by Floyd in 1967, [8] , but it has 
not yet been made practical, and according to Hoare it might well be consid- 
ered a unifying objective which may enforce systematic cooperation from many 
parts of the field. Getting verifying compilers used in practice at a large scale is 
certainly a hard task and Hoare refers to this objective as a ‘grand challenge’ in 
computing. Turning quantum computing into practice, resolving P versus NP, 
proofchecking major parts of mathematics and the theory of computing in the 
tradition of de Bruijn’s type theory, removing worms and viruses from the inter- 
net, and (more pragmatically) the .NET strategy for using the same intermediate 
program notation for all purposes may be viewed as other grand challenges. In 
computational science the adequate simulation of protein unfolding stands out 
as a grand challenge; in system engineering the realization of the computing grid 
and the design of open source environments of industrial strength for all major 
application areas, constitute grand challenges as well. 

Program verification has been advocated by Dijkstra (e.g. in EWD 303) be- 
cause testing and debugging cannot provide adequate certainty. Indeed, if human 
certainty is to be obtained proofs may be unavoidable. For the design of com- 
plex systems, however, the need for proofs is harder to establish. The biological 
evolution of the human mind has produced a complex system, at least from 
the perspective of current computer technology, through a design process using 
natural selection (which seems to be a form of testing rather than a form of 
verification) as its major methodology for the avoidance of design errors. This 
might suggest a way around program verification as well: rather than verify- 
ing program X, one may design a far more complex system C using X and 
many variations of it which is then tested. A test of X may involve millions 
of runs of X and its variations. Usability of C, as demonstrated using tests, 
will provide confidence in components like X, as well as the possibility to use 
these components in a complex setting. Whether confidence or certainty is what 
people expect from computing systems is not an obvious issue, however. As a 
consequence this particular grand challenge has a subjective aspect regarding 
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the value of its objective that the other examples mentioned above seem not to 
have. 

In this section the phenomenon of a verifying compiler will be discussed at 
the level of (state) machine functions and control code algebra. 

9.1 Requirement Codes and Satisfaction Predicates 

REQ will represent a collection of predicates on behaviors that will viewed as 
descriptions of properties of codes under execution, r G REC may serve a s a 
requirement on a behavior. A given predicate sat„^r, for behavior B 

and requirement r G REQ) determines the meaning of requirements. Having 
available the satisfaction predicate at the level of behaviors, it may be gradually 
lifted to source codes. 

If B is the behavior of executable code x on machine m {B = |a;|„m), then 
X sat ^.^r if B sat ^^^r. Further for an assembly code x:a one may write x:a sat ^.^r 
if (ca2e:e • •"^x:a) sat ^.^r. given an assembler c.a2e:e for A. 

For a high-level and machine independent program notation s we define 
X'.ssatgT if {v:s2a:e • •^x:s) sat^.„r for a machine m and a compiler v:s2a:e 
on the same machine m. In the sequel the machine superscripts will be omitted, 
because machine dependence is not taken into account. 

9.2 Proofs and Proof Checking 

Given r it may be viewed a design task to find a control code x : s such that 
x:ssat,.r. A proof for this fact is a code p in a collection PROOFS of codes 
such that p h x:s sat„r, where h is a relation such that p h x\s sat ^r implies 
that x:s sat^r. This implication represents the so-called soundness of the proof 
method. Validating h requires a proof checking tool w.chApAs'.e (check for being 
a proof for an s code) such that w:chApAs:e • »p, x:s, r always terminates, never 
produces an error, and produces the code ”0” exactly if the code p constitutes 
a proof of x:s sat^r. 

Non-automatic Proof Generation. Proving the correctness of control codes 
by hand, as a control code production strategy, amounts to the production of a 
pair {x, p) such that w.chApAs:e**p, x,r = ”0” . Here it is taken for granted that if 
there is to be any chance of obtaining a proof for the control code that code may 
have to be specifically designed with the objective to deliver the required proof 
in mind. It seems to be a folk-lore fact in system verification practice that hand 
made proofs can only be given if the code to be verified is somehow prepared 
for that purpose, though in theory that need not be the case. A complete proof 
method guarantees the existence of a proof for each required fact (concerning 
a code that satisfies a requirement) . But actually finding a proof which theory 
predicts to exist is by no means an easy matter. 

Infeasibility of Proof Search. The task to prove code correctness manually 
(and have it machine checked thereafter) may be considered an unrealistic bur- 
den for the programmer. Therefore control code production methods are needed 
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which can take this task out of the hands of human designers. The most obvious 
strategy is automated proof search. 

Having available a proof method and a proof checker, one may design an 
automated proof generator as a code u:pg4s:e, such that u:pg4s:e»»x:s, r produces 
a proof p with p h x:s sai^r if such a proof exists with the computation diverging 
otherwise (or preferably producing a negative answer, i.e. a code outside REQ). 
Even if a proof checker exists in theory its realization as an executable code with 
useful performance seems to be elusive. Therefore this strategy to avoid the need 
for people to design proofs has been considered infeasible and a different strategy 
is needed. 



9.3 Verifying Compilers 

Given the high-level control code notation s a version as of it that admits an- 
notations is designed. A code in as is considered an annotated code for s. Us- 
ing a tool strip : as2s : e the annotations can be removed and a code in s is 
found which determines the meaning of an annotated s code. In other words: 
x:as • •asU = {strip:as2s:e • »x:as) • •sV- 

A requirement r may will be included as a part of the annotation. The require- 
ment can be obtained (extracted) from the annotated code by means of the ap- 
plication of a tool u:as2r:e. The computation u\as2r.e»»x\as either produces a re- 
quirement r S REQ or it produces an error (M for meaningless) . If a requirement 
is produced that implies that as a part of the extraction the computation has suc- 
ceeded in generating a proof for the asserted program and checking that proof. 
Thus in this case it is guaranteed that strip:as2s:e • ux'-as sat Au\as2r.e • •x:as). 

The production of adequately annotated control code may be simpler than 
the production of proofs as it allows the designer to distribute requirements over 
the code thus simplifying the proofs that the extraction tool needs to find by 
itself. In addition it is held by some that for each construction of a source code 
a ‘natural’ assertion may be found, which the conscious control code author 
should have in mind. This allows to provide a canonical annotation for any 
source code, which can be proved without much trouble. Then follows a stage 
of logic that helps to derive the ‘required’ requirement from a requirement that 
has been automatically synthesized from the canonical annotation. This piece of 
logic needs careful attention, because by itself it is as unfeasible as Pyf NP. The 
asserted code needs a good deal of guidance cast in the form of annotations for 
this matter. 

Verifying Compilers and Multi-part Code. Large amounts of code will be 
organized as multi-part codes, admitting JIT compilation strategies. A compu- 
tation in this setting uses the JIT compiler to transform part after part in an 
(almost) executable form. It may be assumed that verifying compilers are used 
to obtain the various code parts in the code base at hand. It is reasonable to 
assume that these requirements have been stored in a database annex to the 
code base. In that context it is preferable to refer to the stored requirements 
as specifications. Indeed, because the JIT compiler using the various parts must 




40 



J.A. Bergstra 



rely on the use of valid code it cannot accept the possibility that a code part 
defeats the extraction of a requirement. 

Now complimentary to JIT compilation there is JIT requirements integration, 
a process that allows the computation to dynamically synthesize a requirement 
from the requirements known to be satisfied by the various parts it uses. The 
JIT compiler should combine requirements synthesis and verification. This is a 
difficult task that by itself leads to different solution architectures. 

Trivial Requirement Synthesis JIT Compilation. A straightforward way 
to obtain the requirements integration functionality is to assume that all speci- 
fications for parts used during a computation are identical (which is plausible if 
these are understood as global system invariants) , thereby shifting the engineer- 
ing burden to the production of the code base. This solution architecture will be 
called the trivial requirements synthesis JIT architecture (TRS-JIT). 

For TRS-JIT it becomes helpful to admit storing a collection of requirements 
for the various code parts in the annex database. It should be noticed, however, 
that the previous discussion of verifying compilers provides no technique for 
finding a multitude of validated requirements for the same (compiled) code. In 
addition, as the code base contains code parts with different requirements (stored 
in the annex data base), the JIT compiler now faces the possibility of running 
into a code part that is not equipped with a suitable requirement. It may be the 
case that the requirement for the part is logically stronger than needed, but that 
is impossible to check dynamically. Thus it must be accepted that executions may 
always stop in an error condition indicating that a part had to be JIT compiled 
for which the needed requirement was absent. This is a severe drawback because 
it is useless for real time control applications. If this drawback is unacceptable 
the JIT compiler must be shown always to ask for a code that exists in the code 
base and that is equipped with the required specification. 

A Verifying JIT Compiler. Guaranteeing that a computation will not halt at 
an ill-specified of even absent code part is the task of the verifying JIT compiler 
in the case of the trivial requirements synthesis architecture. This leads to a two- 
phase strategy that first checks this latter property using a dataflow analysis on 
the initial code, and thereafter a check that all needed parts are equipped with 
the required specification. In this stage a limited amount of proof generation 
may be used to allow parts that have logically stronger specifications to be used 
if the required specifications can be derived by these limited means. 

10 Conclusion 

Machine functions have been used to formalize several software processing mech- 
anisms at a high level of abstraction, by means of the formation of code algebras. 
This abstract formalization has been proposed in particular for compilation, as- 
semblage, interpretation, and for managed and unmanaged, interpreted and just 
in time compiled multi-part code execution, and for verifying compilers. While 
the notion of a verifying compiler can be captured to some extent at the ab- 
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straction level of CCA, this seems not to be the case for the unavidable concept 
of a verifying JIT compiler, however. 
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Abstract. From the models provided in [14] and [4] for the semantics of 
Java and CH programs we abstract the mathematical structure that un- 
derlies the semantics of both languages. The resulting model reveals the 
kernel of object-oriented programming language constructs and can be 
used for teaching them without being bound to a particular language. It 
also allows us to identify precisely some of the major differences between 
Java and C#. 



1 Introduction 

In this work the models developed in [14] and in [4] for a rigorous definition 
of Java and Cj] and their implementations on the Java Virtual Machine (JVM) 
resp. in the Common Language Runtime (CLR) of .NET are analyzed to ex- 
tract their underlying common mathematical structure. The result is a platform- 
independent interpreter of high-level programming language constructs which 
can be instantiated to concrete interpreters of specific languages like Java, CjJ, 
C-|— b. It is structured into components for imperative, static, object-oriented, 
exception handling, concurrency, pointer related, and other special language fea- 
tures (like delegates in CjJ) and thus can be used in teaching to introduce step 
by step the basic concepts of modern programming languages and to explain the 
differences in their major current implementations. 

The task is supported by the fact that the models in [14, 4] have been defined 
in terms of stepwise refined Abstract State Machines (ASMs), which 

■ separate the static and the dynamic parts of the semantics, 

■ capture the dynamics by ASM rules, one rule set for each cluster of language 
constructs^, describing their run-time effect on the abstract program state, 
guided by a walk through the underlying attributed abstract syntax tree. 



^ A related modular approach, to define the semantics of a language by a collection 
of individual language construct descriptions, now named “incremental semantics”, 
appears in [12, 6]. 
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The stepwise refined definitions unfold in particular the following layered 
modules of orthogonal language features, which are also related to the historical 
development of programming concepts from say FORTRAN, via PASCAL and 
MODULA, SMALLTALK and EIFFEL, to JAVA and Cji: 

■ imperative constructs, related to sequential control by while programs, built 
from statements and expressions over simple types, 

■ classes with so-called static class features, namely procedural abstraction 
with class initialization and global (module) variables, 

■ object-orientation with class instances, instance creation, instance methods, 
inheritance, 

■ exception handling, 

■ concurrency (threads), 

■ special features like delegates, events, etc. 

■ so-called unsafe features like pointers with pointer arithmetic. 

This leads us to consider a sequence of sublanguages Lx C L^ C Lq C L^ C 
Lx C Lx) C Lx/ of a general language L, which can be instantiated to the corre- 
sponding sublanguages of Java and CjJ defined in [14, 4]. The interpreter ExecLs 
of each language L 5 in the sequence conservatively (purely incrementally) ex- 
tends its predecessor. We show how it can be instantiated to an interpreter of 
Java^ or CjJ^ by variations of well-identified state or machine components. The 
interpreter ExecL of the entire language L is the parallel composition of those 
submachines: 

ExecL = 

ExecL/ 

ExecL c 
ExecL o 
ExecLb 
ExecL X 
ExecL/) 

ExecL// 

Delegates and unsafe code are peculiar features of CjJ and not included at 
all into Java, therefore we refer for the two corresponding submachines to [4]. 
Since the thread models of Java and Cj) have been analyzed and compared ex- 
tensively in [14, 1, 13], we skip here to reformulate the interpreter ExecL x. The 
static semantics of most programming languages can be captured appropriately 
by mainly declarative descriptions of the relevant syntactical and compile-time 
checked language features, e.g., typing rules, control-flow analysis, name reso- 
lution, etc.; as a consequence we concentrate our attention here on the more 
involved language dynamics for whose description the run-time oriented ASM 
framework turns out to be helpful. So we deal with the static language features 
in the form of conditions on the attributed abstract syntax tree, resulting from 
parsing and elaboration and taken as starting point of the language interpreter 
ExecL. 
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This paper does not start from scratch. We tailor the exposition for a reader 
who has some basic knowledge of (object-oriented) programming. A detailed 
definition of ASMs and their semantics, as originally published in [11], is skipped 
here, because ASMs can be correctly understood as pseudo-code operating over 
abstract (domains of) data. A textbook-style definition is available in Chapter 2 
of the AsmBook [5] . 



2 The Imperative Core Lx 

In this section we define the sequential imperative core Lx of our general lan- 
guage L together with a model for its semantics. The model takes the form of 
an interpreter ExecL/, which defines the basic machinery for the execution of 
the single language constructs. Lx provides structured while-programs consist- 
ing of statements to be executed (appearing in method bodies), which are built 
from expressions to be evaluated, which in turn are constructed using predefined 
operators over simple types. The computations of our interpreter are supposed 
to start with an arbitrary but fixed i^program. As explained above, syntax and 
compile-time matters are separated from run-time issues by assuming that the 
program is given as an attributed abstract syntax tree, resulting from parsing 
and elaboration. 

2.1 Static Semantics of Lx 

Expressions and statements of the sublanguage Lx are defined as usual by a 
grammar, say the one given in Fig. 1. We view this figure as defining also the 
corresponding ASM domains, e.g., the set Exp of expressions built from Literals 
and variable expressions using the provided operators (unary, binary, condi- 
tional) and including besides some possibly language-specific expressions the set 
Sexp of statement expressions, i.e., expressions than can be used on the top-level 
like an assignment to a variable expression using ‘=’ (or an assignment operator 
from a set Aop or one of the typical prefix/postfix operators ‘++’ or ‘ — ’). In 
this model the set Vexp of variable expressions (lvalues) consists of the local 
variables only and will be refined below. The prefix operators ‘++’ and ‘ — ’ are 
syntactically reduced to assignment operators, e.g., ++w is reduced to v += 1. 

The auxiliary sets, like Uop of unary operators, which one may think of as in- 
cluding also operators to construct type cast expressions of form ‘ (’ Type ‘) ’ Exp, 
vary from language to language. SpecificExp(L) may include expressions that are 
specific for the language L, like ‘checked’ ‘(’ Exp ‘)’ and ‘unchecked’ ‘(’ Exp ‘)’ 
in the model Cflx in [4, Fig. 1]. In the model Javax in [14, Fig. 3.1] the set 
SpecificExp{L) is empty. Similarly, the set JumpStm of jump statements may 
vary from language to language; in Javax it consists of ‘break’ Lab ‘;’ and 
‘continue’ Lab in Cflx of ‘break’ ‘;’ | ‘continue’ ‘;’ | ‘goto’ Lab 
SpecificStm{L) may contain statements that are specific to the language L, e.g., 
‘checked’ Block \ ‘unchecked’ Block for the language CjJx- In Javax it is empty. 
Bstm may also contain block statements for the declaration of constant expres- 
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Exp Lit I Vexp \ Uop Exp \ Exp Bop Exp \ Exp “?’ Exp ‘ : ’ Exp 
I Sexp I SpecificExp(E) 

Vexp ::= Loc 

Sexp ::= Vexp ‘=’ Exp \ Vexp Aop Exp \ Vexp ‘++’ | Vexp ‘ — ’ 

Stm ::= ‘ | Sexp ‘ | Lab ‘ : ’ Stm \ JumpStm 

I ‘if’ ‘ (’ Exp ‘) ’ Stm ‘else’ Stm \ ‘while’ ‘ (’ Exp ‘) ’ Stm 
I SpecificStm(L) \ Block 

Block :;= ‘{’ {Bstm} ‘>’ 

Bstm ::= Type Loc ‘ ; ’ | Stm 

Fig. 1. Grammar of expressions and statements in Li 



sions whose value is known at compile time, like ‘const’ Type Loc ‘=’ Cexp 
in Cjlx- 

Not to burden the exposition with repetitions of similar arguments, we do 
not list here statements like do, for, switch, goto case, goto default, etc., 
which do appear in real-life languages and are treated analogously to the cases 
we discuss here. When referring to the set of sequences of elements from a set 
Item we write Items. We usually write lower case letters e to denote elements 
of a set E, e.g., lit for elements of Lit. For expository purposes, in Fig. 1 we 
also neglect that in Cjl labeled statements are only allowed as block statements, 
whereas in Java, every statement (also embedded statements) can have a label. 

Different languages usually exhibit not only differences in syntax, but above 
all different notions of types with their conversion and promotion rules (sub- 
type or compatibility definition), different type constraints on the operand and 
result values for the predefined operators, different syntactical constraints for 
expressions and statements like scoping rules, definite assignment and reachabil- 
ity rules, etc. As a consequence, the static analysis differs, e.g., to establish the 
correctness of the definite assignment conditions or more generally of the type 
safety of well-typed programs (for Java see the type safety proof in [14, Ch. 8], 
for CjJ see the proof of definite assignment correctness in [8]). Since this paper is 
focused on modeling the dynamic semantics of a language, we omit here any gen- 
eral discussion of standard static semantics issues and come back to them only 
where needed to explain how the interpreter uses the attributed abstract syntax 
tree of a well-typed program. E.g., we will use that each expression node exp 
in the attributed syntax tree is annotated with its compile-time type type(exp), 
that type casts are inserted in the syntax tree if necessary (reflecting implicit 
type conversions at compile-time), etc. 



2.2 Dynamic Semantics of Lx 

The dynamic semantics for Lx describes the effect of statement execution and of 
expression evaluation upon the program execution state, so that the transition 
rule for the Lx interpreter (the same for its extensions) has the form 
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ExecL/ = 

ExecLExp/ 

ExecLStm/ 

The first subrule defines one execution step in the evaluation of expressions; 
the second subrule defines one step in the execution of statements. 



Syntax Tree Walk. To facilitate further model refinements by purely incre- 
mental extensions, the definition proceeds by walking through the abstract syn- 
tax tree, starting at pos = root-position, to compute at each node the effect of 
the program construct attached to the node. We formalize the walk by a cursor 
► , whose position in the tree - represented by a dynamic function pos: Pos - is 
updated using static tree functions, leading from a node in the tree down to its 
first child, from there to the next brother or up to the parent node (if any), as 
illustrated by the following self-explanatory example. Pos is the set of positions 
in the abstract syntax tree. A function label: Pos —>■ Label decorates nodes with 
the information which identifies the grammar rule associated with the node. For 
the sake of notational succinctness and in adherence to widespread program- 
ming notations, we use some concrete syntax from Java or Cj) to describe the 
labels, thus hiding the explicit introduction of auxiliary non-terminals^. In the 
example the label of the root node is the auxiliary non-terminal If, identifying 
the grammar rule which produces the construct if {exp) stmi else stni2 — the 
‘occurrence’ of which here constitutes what we are really interested in when con- 
sidering the tree. As explained below, this construct determines what we will 
call the context of the root node or of its children nodes. 




Local Variable Values. The next question is what are the values computed 
for expressions and how they are stored as current values of local variables, 
namely upon executing an assignment statement or as side effect of an expres- 
sion evaluation. The answer to the second question depends upon whether such 
values are stored directly, as for example in Java, or indirectly via an addressing 
mechanism, as for example in Cf. To capture both possibilities we introduce two 
domains, namely of values and of addresses, and use the following two dynamic 
functions 

locals: Loc Adr, mem: Adr Simple Value U { Undef} 



^ In [12] an abstract syntax notation is proposed which avoids Java or C# like notation. 
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which can be used to assign memory addresses to local variables and to store the 
values there. To simplify the formulation of how to instantiate our interpreter 
for Java or CjJ and to prepare the way for later refinements, we use a macro 
WRiTEMEM(adr, t, vaZ) to denote writing a value of given type t to a given 
address. For the sublanguage Lx (as for Java) the macro is only an abbreviation 
for mem{adr) := val, which will be refined in the model for Lq. 

One possible instance of this scheme, namely for Java, is to identify Loc 
and Adr so that locals becomes mem. It goes without saying and will not be 
mentioned any more in the sequel that a similar simplification applies to all other 
functions, predicates, and macros introduced below in connection with handling 
the values stored at addresses. 

Since the values we consider in Lx are of simple types, in this model the 
equation 

Value = Simple Value U Adr 

holds, which will be refined for Lq to include references (and structs, which 
appear in Ct(). The fact that local variables have to be uniquely identified can 
be modeled by stipulating Loc = Identifier x Pos. For the initialization of the 
interpreter it is natural to require that an address has been assigned to each 
local variable, but that the value stored there is still undefined. 

■ locals (x) € Adr for every variable x 

■ mem{i) = Undef for every i G Adr 

Recording Intermediate Values. During the walk through the tree, also in- 
termediate results of the elaboration of syntactical constructs appear, which have 
to be recorded somewhere, namely values of evaluated (sub-) expressions, but 
also possible results of the execution of statements. Statements may terminate 
normally, but also abruptly due to jumps (in Lx) or returns from method calls 
(in Lc) or to the occurrence of exceptions (in Lx). There are many ways to keep 
track of such temporary items, e.g., using a stack (as do many virtual machines, 
see for example the Java Virtual Machine operand stack opd in [14, pg. 140]), 
or replacing directly the elaborated syntactical constructs by their intermedi- 
ate result (as do SOS-based formalisms, see for example the restbody concept 
in [14, pg. 38]), or via some dynamic functions defined on the static syntax tree. 
We choose here to use a partial function to record the values computed for the 
syntactic construct labeled by the node with each node. 

values: Pos Result 

For Lx, the range Result of this function contains a) Undef, to signal that 
no value is defined yet, b) simple values, resulting from expression evaluation, 
c) Norm, for normal termination of statement execution, and d) reasons for 
abruption of statement execution. The set Ahr of abruptions derives here from 
the jump statements (see below) and will be refined in successive models to also 
contain statement returns and exceptions. 

Result = Value U Ahr U { Undef, Norm} 
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As intermediate values at a position p the cursor is at or is passing to, the 
computation may yield directly a simple value; at AddressPositions as defined 
below it may yield an address; but it may also yield a memValue which has to be 
retrieved indirectly via the given address (where for Lx the memory value of a 
given type t at a given address adr is defined by memValue{adr , t) = mem{adr); 
the parameter t will become relevant only in the refinements of memValue in 
Lq and Lu). This is described by the following two macros: 

YiELD(?;aZ, p) = 
values{p) := val 
pos := p 

YlELDlNDIRECT(adr, p) = 

if AddressPos(p) then YiELD(adr, p) 
else YiELD(mem VaZMe(adr, type{p)),p) 

We will use the macros in the two forms YiELD(uaZ) = YiELD(uaZ, pos) and 
YiELDUp(uaZ) = Yield ( vaZ, rtp(pos)), similarly for YiELDlNDiRECT(adr) and 
YieldU pIndirect ( adr) . 

A context where an address and not a value is required characterizes the con- 
text of first children of parent nodes labeled with an assignment or prefix/postfix 
operator. It can thus be defined as follows: 

AddressPos(a) 4=^ FirstChild{a) A label{up{a)) £ {++, — } U Aop 

FirstChild{a) 4=^ first{up{a)) = a 



Notational Conventions. To reduce any notational overhead not needed by 
the human reader, in spelling out the ASM rules below we identify positions 
with the occurrences of the syntactical constructs nodes encode via their labels 
and those of their children. This explains updates like pos := exp or pos := stm, 
which are used as shorthand for updating pos to the node labeled with the 
corresponding occurrence of exp respectively stmA 

For a succinct formulation of the interpreter rules we use a macro context {pos) 
to describe the context of the expression or statement currently to be handled in 
the syntax tree. context{pos) has to be matched against the cases appearing in 
the ASM rules below, choosing for the next computation step the first possible 
match following the textual order of the rules. If the elaboration of the subtree at 
the position pos has not yet started, then context{pos) is the construct encoded 
by the labels of pos and of its children. Otherwise, if pos carries already its 
result in values, context{pos) is the pseudo-construct encoded by the labels of 
the parent node of pos and of its children after replacing the already evaluated 
constructs by their values in the corresponding node. This explains notations like 
uop ^val to describe the context of pos, where pos is marked with the cursor 



® An identification of this kind, which is common in mathematics, has clearly to be 
resolved in an executable version of the model. 
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(►), resulting from the successful evaluation of the argument exp of the construct 
uop exp (encoded by up{pos) and its child pos), just before uop is applied to val 
to YiEhT>\Ji>{Apply{uop,val)). 

Expression Evaluation Rules. We are now ready to define ExecLExP/, the 
machine for expression evaluation. We do this in a compositional way, namely 
proceeding expression-wise: for each group of structurally similar expressions, 
defined by an appropriate parameterization described in Fig. 1,^ there is a set 
of rules covering each intermediate phase of their evaluation. SpecificExpressions 
of L are separately discussed below. The machine passes control from uneval- 
uated expressions to the appropriate subexpressions until an atom (a literal or 
a local variable) is reached. It can continue its computation only as long as 
no operator exception occurs (see below for the definition of UopException and 
Bop Exception). When an operator has to be applied, we use a static function 
Apply to determine the value the operator provides for the given arguments. 
This function can be separately described, as is usually done in the language 
manual. Similarly for the static function defining the ValueOf Literals. 

ExecLExp/ = match context(pos) 
lit Yield( ValueOfLiteral{lit)) 
loc — > YieldIndirect (;ocaZs(Zoc)) 
uop exp pos := exp 

uop *’val — > if ^UopException{uop, val) then 
YieldUp {A pply {uop, val)) 
expi bop exp2 pos := expi 
^val bop exp pos := exp 

vail bop *’val2 if -^BopException{bop,vali,val2) then 
YieldUp {Apply {bop, val\, vah)) 
expo ? oxpi : exp2 pos := expo 

*'val ? expi : exp2 if val then pos := expi else pos := exp2 

True ? *'val : exp — > YiELDUp(uaZ) 

Ealse ? exp : *'val YiELDUp(uaZ) 

loc = exp pos := exp 

loc = *’val {WRiTEMEM(Zocafe(Zoc), type{loc), val), YiELDUp(waZ)} 
vexp op= exp pos := vexp 
adr op= exp — > pos := exp 

adr op= val — > let t = type{up{pos)) and v = memValue{adr , t) in 
if ~^BopException{op, v, val) then 
let w = Apply {op, v, val) in 
let result = Convert{t, w) in 
WriteMem( adr, t, result) 

YieldUp {result) 

^ The desired specializations can be obtained expression-wise by mere parameter ex- 
pansion, a form of refinement that is easily proved to be correct. 
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vexp op — > pos := vexp j j for postfix operators op G {++, — } 

adr op let old = memValue{adr , type(pos)) in 
if -^UopException{op, old) then 

WRiTEMEM(arfr, type {up {po s)) , Apply {op , old)) 
YieldUp(oW) 

SpecificExp/ 

Note that in an assignment operator op= the result of the operation has to 
be converted back to the type of the variable expression, e.g., if c is a variable 
of type char, then c += ’A’ is evaluated as c = (char)(c + ’A’), since the 
operands of + are promoted to the type int in Java as well as in Cf. 



Language- Specific Expressions. In Javax the set of SpecificExpressions and 
therefore the submachine SpecificExP/ is empty, whereas in the model for CUx 
the set contains checked and unchecked expressions ‘checked’ ‘(’ Exp ‘)’ and 
‘unchecked’ ‘(’ Exp ‘)’. The notion of Checked positions serves to define when 
an operator exception occurs due to arithmetical Overflow (for which case a rule 
will be added in the model for Lx). The principle is that operators for integral 
types only throw overflow exceptions in a checked context except for the division 
by zero; operators for the type decimal always throw overflow exceptions. By 
default every position is unchecked, unless explicitly declared otherwise. This is 
formally expressed as follows. 

UopException{uop,val) Checked{pos) A Overflow {uop,val) 

BopException{bop,vali,val2) 

DivisonBy Zero {bop, vah) V DecimalOverflow{bop , val\, vah) V 
{Checked{pos) A Overflow{bop,val\,val2)) 

Checked{a) label{a) = Checked V 

{label{a) yf Unchecked A up{a) yf Undef A Checked {up {a))) 

As a consequence of these definitions and of the fact that the extension by 
rules to handle exceptions is defined in the model extension ExECLg, the fol- 
lowing SpecificExp/ rules of ExFcCjJ/ do not distinguish between checked and 
unchecked expression evaluation. 

match context{pos) 

checked) exp) — > pos := exp 

checked(^waZ) — > YiELDUp(waZ) 

unchecked) exp) — > pos := exp 
unchecked)^ xaZ) ^ YiELDUp(xaZ) 

Statement Execution Rules. The machine ExecLStM/ is defined statement- 
wise. It transfers control from structured statements to the appropriate substate- 
ments, until the current statement has been computed normally or abrupts the 
computation. Abruptions trigger the control to propagate through all the enclos- 
ing statements up to the target labeled statement. The concept of propagation is 
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defined for Lx in such a way that in the refined model Lg the concept of finally 
blocks can easily be specified. In case of a new execution of the body of a while 
statement, the previously computed intermediate results have to be cleared.^ 
Since we formulate the model for the human reader, we use the . . .-notation, 
for example in the rules for abruption or for sequences of block statements. 
This avoids having to fuss with an explicit formulation of the context, typically 
determined by a walk through a list. 

ExecLStM/ = match context{pos) 

; YiELD{Norm) 

exp ; pos := exp 
*’val\ ^ YiELDUp(A^orm) 

JumpStm(L) 

if iexp) stmi else stm2 pos := exp 

if val) strrii else stm2 if val then pos := strui else pos := strri2 
if (True) *’Norm else stm YiELDUp(Yorm) 
if (False) stm else ^ Norm YielbXJp (N orm) 

while (exp) stm pos := exp 

while (^val) stm if val then pos := stm 

else YiELDUp(A^orm) 

while (True) *’Norm {pos := up{pos), ClearValues(mp ( pos))} 

Propagate Jump(L) 

type loc; Yield (Norm) 

lab: stm pos := stm 

lab: ^ Norm ^ YiELD\Jp{Norm) 

SpecificStm/ 

. . . ^ abr ... ^ if up{pos) yf Undef A PropagatesAbr{up{pos)) then 
YiELDUp(o&r) 

{ } — > YiELD(A^orm) 

{stm . . . } ^ pos := stm 

{... ^Norm} ^ YieldVp (N orm) 

{ . . . ^ Norm stm . . . } ^ pos := stm 

JumpOutOfBlockStm 

{... *' abr ...} ^ YiELDUp(a&r) 

In Javax the set JumpStm consists of the jump statements break lab; and 

continue lab;, so that the set of abruptions is defined as Abr = Break{Lab) \ 

® ClearValues is needed in the present rule formulation due to our decision to have 
a static function label and a dynamic function to record the intermediate values 
associated to nodes. In a more syntax-oriented SOS-style, as used for the Java model 
in [14] where a function restbody combines the two functions label and values into 
one, ClearValues results automatically from re-installing the body of the while 
statement as new rest program. 
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Continue{Lab) . In C|Jx the set JumpStm contains the jump statements break; | 
continue; | goto lab;, so that Abr = Break \ Continue \ Goto(Lab). The 
differences in the scoping rules for break; and continue; statements in the two 
languages are reflected by differences in the corresponding interpreter rules. 

JuMPSTM(Ja?;a) = match context(pos) 
break Za&; YiELD{Break{lab)) 

continue lab; YiELD(Continue{lab)) 

PropagateJump( J ava) = match context(pos) 

lab: ^ Break(labb) if lab = labb then YiELDUp(A^orm) 

else YiELDlJp(i?reofc(Za&f,)) 
lab: Continue{labc) if lab = labc then 

{pos := up{pos), ClearValues(mp(pos))} 
else YiELDUp(C'ontmMe(Za&c)) 

JuMPSTM(CjJ) = match context{pos) 
break; —> Yield ( iJreafc) 
continue; ^ YiELD(C'ontmMe) 
goto lab; YiELi){Goto{lab)) 

PROPAGATEJuMP(Cjl) = match context{pos) 
while (True) Break ^ YieloXJp (N orm) 

while (True) Continue {pos := up{pos), ClearValues(mp(pos))} 
while (True) *' abr — > YiELDUp(o&r) 

Due to the differences in using syntactical labels to denote jump statement 
scopes, the definitions of how abruptions are propagated upwards differ slightly 
for Javax and for Cflx, though the conceptual content is the same, namely to pre- 
vent propagation at statements which are relevant for determining the abruption 
target. For Javax we have the simple definition® 

Propagates Abr (^a) label (a) yf LabeledStm 

whereas for Cjlx we have the following definition: 

Propagates Abr {a) label{a) ^ {Block, While, Do, For, Switch} 

Since Java has no goto statements, it has an empty JumpOutOfBlockStm 
rule, whereas ExecCSStM/ contains the rule 

JumpOutOfBlockStm = match context(pos) 

{ . . . ^Goto(l) ...}—> let a = GotoTarget{first{up{pos)), 1) 

if a yf Undef then 

{pos := a, ClearValues(mp ( pos))} 
else YiELDUp(G'oto(Z)) 



We disregard here the minor difference in the formulation of PropagatesAbr in [14], 
where the arguments are not positions, but syntactical constructs or intermediate 
values. 




Exploiting Abstraction for Specification Reuse 



53 



where an auxiliary function is needed to compute the target of a label in a list 
of block statements, recursively defined as follows: 

GotoTarget{a, 1) = 
if label{a) = Lab{l) then a 
elseif next (a) = Undef then Undef 
else GotoTarget{next{a),l) 

Analogously to ExecCHExp/ also ExecCUStm/ has checked contexts and 
therefore the following submachine (which in ExecJavaStm/ is empty): 

SpecificStm/ = match context(pos) 
checked block —>■ pos := block 
checked ^ Norm YiELDUp(Aorm) 

unchecked block pos := block 

unchecked ^ Norm YiELDUp(Aorm) 

The auxiliary macro CLEARVALUES(a) to clear all values in the subtree at 
position a can be defined by recursion as follows, proceeding from top to bottom 
and from left to right^: 

CLEARVALUES(a) = 
values(a) := Undef 

if first{a) yf Undef then CLEARVALUESSEQ(/irst(Q;)) 

CLEARVALUESSEQ(a) = 

CLEARVALUES(a) 

if next{a) yf Undef then CLEARVALUESSEQ(nea;t(a)) 

3 Extension Lc of Lx by Procedures (Static Classes) 

In Lc the concept of procedures (also called subroutines or functions) is added 
to the purely imperative instructions of Lx- We introduce the basic mechanism 
of procedures first for so-called static methods, which belong to classes playing 
the role of modules. Different languages have different mechanisms to pass the 
parameters to a procedure call. In Java parameters are passed by- value, whereas 
in Cj) also call-by-reference is possible. Classes® come with variables which play 
the role of global module variables, called class or static variables or fields to 
distinguish them from instance fields provided in Lq . Usually classes come with 
some special methods, so-called static initializers or static constructors, which 
are used to ‘initialize’ the class. The initialization concepts of different languages 
usually differ, in particular through different policies of when a class is initial- 
ized. In the extension ExecLc of ExecL/ we illustrate these differences for Java 



^ Intuitively it should be clear that the execution of this recursive ASM provides 
simultaneously - in one step - the set of all updates of all its recursive calls, as is 
needed here for the clearing purpose; see [3] for a precise definition. 

® We disregard here the slight variations to be made for interfaces. 
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and Cjl. Normally classes are also put into a hierarchy, which is used to inherit 
methods among classes to reduce the labor of rewriting similar code fragments. 
As is to be expected, different languages come with different inheritance mech- 
anisms related to their type concepts. Since the definition of the inheritance 
mechanism belongs mainly to the static semantics of the language, we mention 
it only where it directly influences the description of the dynamics. 

We present the extension as a conservative (purely incremental) refinement 
of the ASM ExecL/, which is helpful for proving properties of the extended 
machine on the basis of properties of the basic machine. Conservative refinement 
means that we perform the following three tasks (see [2] for a general description 
of the ASM refinement method). 

■ Extension of the ASM universes and functions, or introduction of new ones, 
for example to reflect the grammar extensions for expressions and state- 
ments. This goes together with the addition of the appropriate constraints 
needed for the static analysis of the new items (like type constraints, definite 
assignment rules, etc.). 

■ Extension of some of the definitions or macros, here for example the predicate 
Propagates Abr (a), to make them work also for the newly occurring cases. 

■ Addition of new ASM rules, in the present case to define the semantics of 
the new expressions and statements. 

3.1 Static Semantics of Lc 

In Lc a program is a set of compilation units, each coming with declarations of 
names spaces (also called packages), using directives (import declarations), type 
declarations (classes, interfaces, structs and enumerations), conditions on class 
extension, accessibility, visibility, etc. Since in this paper the focus is on dynamic 
semantics, we assume nested namespaces to be realized by the adoption of fully 
qualified names. We also do not discuss here the rules for class extensions (in- 
heritance), for overriding of methods, for the accessibility of types and members 
via access modifiers like public, private, etc. This allows us to make use, for 
example, of a static function body{m) which associates to a method its code. 

The extension of the grammars for Vexp, Sexp, Stm and thereby of the corre- 
sponding ASM domains reflects the introduction of Classes with static Fields and 
static Methods, which can be called with various arguments and upon returning 
may pass a computed value to the calling method. The new set Arg of arguments 
appearing here foresees that different parameters may be used. For example, Java 
provides value parameters (so that Arg ::= Exp), whereas CjJ allows also ref and 
out parameters (in which case Arg ::= Exp \ ‘ref’ Vexp \ ‘out’ Vexp). We do 
not discuss here the different static constraints (on types, definite assignment, 
reachability, etc.) which are imposed on the new expressions and statements in 
different languages.® 



® See for example [8] for a detailed analysis of the extension of the definite assignment 
rules needed when allowing besides by-value parameter passing (as does Java) also 
call-by-reference (as does Ctl). 
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Vexp 


:= . . . Field Class ‘ . ’ 


Field 


Sexp 


:= . . . Meth ( [Args] ) 


Class ‘ . ’ Meth ( [Args] ) 


Args 


:= Arg Arg} 




Stm 


:=...] ‘return’ Exp ‘ ; 


’ ‘return’ ‘ ; ’ 



The presence of method calls and of to-be-initialized classes makes it nec- 
essary to introduce new universes to denote multiple methods (pairs of type 
and signature), the initialization status of a type (which may have additional 
elements in specific languages, e.g.. Unusable for the description of class initial- 
ization errors in Java, see below) and the sequence of still active method calls 
(so-called frame stack of environments of method executions). One also has to 
extend the set Ahr of reasons for abruption by returns from a method, with or 
without a computed value which has to be passed to the caller. 

Meth = Type x Msig 

TypeState = Linked \ InProgress \ Initialized 

Frame = Meth x Pos x Locals x Values 
where Values = {Pos Result) and Locals = {Loc Adr) 

A method signature Msig consists of the name of a method plus the sequence 
of types of the arguments of the method. A method is uniquely determined by 
the type in which it is declared and its signature. The reasons for abruptions are 
extended by method return: 

Ahr = • . • I Return \ Return{ Value) 

3.2 Dynamic Semantics of 

To dynamically handle the (addresses of) static fields, the initialization state of 
types, the current method and the execution stack, we use the following new 
dynamic functions: 

globals: Type x Field Adr frames: List{Frame) 

typeState: Type TypeState meth: Meth 

To allow us to reuse without any rewriting the ExecL/ rules as part of the 
ExecLc rules, we provide a separate notation {meth, pos, locals, values) for the 
current frame, instead of having it on top of the frame stack. We extend the 
stipulations for the initial state as follows: 

■ typeState{c) = Linked for each class c 

■ meth = Entry Point: 'Main O 

■ pos = body{meth) 

■ locals = values = 0 and frames = [] 

The submachine ExecL c extends the interpreter ExecL/ for Lj by addi- 
tional rules for the evaluation of the new expressions and for the execution of 
return statements. In the same way the further refinements in the sections below 
consist in the parallel addition of appropriate submachines. 



[EntryPoint is the main class] 
[The root position of the body] 
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ExecLc = 

ExecLExpc 

ExecLStM(7 

Expression Evaluation Rules. The rules in ExecLExp^ for class field evalu- 
ation are analogous to those for the evaluation of local variables in ExecLExp/, 
except for using globals instead of locals and for the additional clause for class ini- 
tialization. The rules for method calls use the macro InvokeStatic explained 
below, which takes care of the class initialization. The submachine ArgEval 
for the evaluation of sequences of arguments depends on the evaluation strat- 
egy of L. The definition of the submachine ParamExp for the evaluation of 
special parameter expressions depends on the parameter types provided by the 
language L. If Arg = Exp as in Java, this machine is empty; for the case of CjJ, 
where Arg ::= Exp \ ‘ref’ Vexp \ ‘out’ Vexp, we show below its definition. 

ExecLExp c = match context{pos) 

c.f if Initialized{c) then YiELDlNDiRECT(gZo&afe(c::/)) 
else Initialize(c) 

c.f = exp pos := exp 

c.f = *'val ^ if Initialized{c) then 

WRiTEMEM(5Zo&aZs(c::/), type{c::f) , val) 

YiELDUp(waZ) 
else Initialize(c) 

c.m(args) ^ pos := (args) 

c.m*' ivals) — > lNVOKESTATic(c::m, waZs) 

ArgEval 

ParamExp 

Once the arguments of a method call are computed, InvokeStatic invokes 
the method if the initialization of its class is not triggered, otherwise it initial- 
izes the class. In both Java and Cjl, the initialization of a class is not triggered 
if the class is already initialized. For methods which are not declared exter- 
nal or native, InvokeMethod updates the frame stack and the current frame 
in the expected way (the same in both Java and CU), taking care also of the 
initialization of local variables, which includes passing the call parameters. Con- 
sequently the definition of the macro InitLocals depends on the parameter 
passing mechanism of the considered language L, which is different for Java 
and for CjJ. Since we will also have to deal with external (native) methods - 
whose declaration includes an extern (native) modifier and which may be im- 
plemented using a language other than L — we provide here for their invocation 



See [9] for other cases where the initialization is not triggered in C#, in partic- 
ular the refinement for classes which are marked with the implementation flag 
bef oref ieldinit to indicate that the reference of the static method does not trigger 
the class initialization. 




Exploiting Abstraction for Specification Reuse 



57 



a submachine InvokeExtern, to be defined separately depending on the class 
of external/native (e.g. library) methods. The predicate StaticCtor recognizes 
static class constructors (class initialization methods); their implicit call inter- 
rupts the member access at pos, to later return to the evaluation of pos instead 
of up{pos). 

lNVOKESTATic(c::m, uaZs) = 

if triggerlnit(c) then Initialize(c) else lNVOKEMETHOD(c::m, vals) 
where triggerlnit{c) = Initialized {c) A ^BeforeFieldlnit(c) 

lNVOKEMETHOD(c::m, waZs) = 

if extern G modifiers {c::m) then lNVOKEExTERN(c::m, wafe) 
else let p = if StaticCtor {c/.m) then pos else up{pos) in 
frames := push{frames , {meth, p, locals, values)) 
meth := c::m 
pos := body{c::m) 
values := 0 

lNiTLoCALS(c::m, vals) 

The definition of the macro InitLocals for the initialization of local vari- 
ables depends on the parameter passing mechanism. In Java the macro simply 
defines locals (which assumes the role of mem in our general model) to take as 
first arguments the actual values of the call parameters (the ValueParams for 
call-by- value) . In CD one has to add a mechanism to pass reference parameters, 
including so-called out parameters, which can be treated as ref parameters ex- 
cept that they need not be definitely assigned until the function call returns. 
In the following definition of InitLocals for CD, all (also simultaneous) appli- 
cations of the external function new during the computation of the ASM are 
supposed to provide pairwise different fresh elements from the underlying do- 
main Adrf^ paramlndex{c::m, x) yields the index of the formal parameter x in 
the signature of c::m. 

lNiTLoCALS(c::m, uafo)(CD) = 

forall X G LocalVars{c::m) do // addresses for local variables 

locals{x) := new{Adr, type{x)) 

forall X G ValueParams{c::m) do // copy value arguments 

let adr = new{Adr, type{x)) in 
locals (x) := adr 

WRiTEMEM(odr, type{x), vals{paramlndex{c::m, x))) 
forall X G RefParams{c::m) U OutParams{c::m) do 

locals{x) := vals{paramlndex{c::m, x)) // ref and out arguments 

The difference between ref and out parameters at function calls and in 
function bodies of CD is reffected by including as AddressPositions all nodes 



See [10] and [5, 2.4.4] for a justification of this assumption. See also the end of Sect. 4 
where we provide an abstract specification of the needed memory allocation. 
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whose parent node is labeled by ref or out and by adding corresponding definite 
assignment constraints (listed in [4]): 

AddressPos{a) FirstChild{a)/\lahel{up{a))&{i:ef,o-a.t,++, — }UAop 

Therefore the following rules of ParamExp for Ctt can ignore ref and out: 

PARAMExp(Cjl) = match context (pos) 
ref vexp pos := vexp 

ref *' adr YiELDUp(adr) 

out vexp pos := vexp 

out *' adr YiELDUp(adr) 

For the sake of illustration we provide here a definition for the submachine 
ArgEval with left-to-right evaluation strategy for sequences of arguments. The 
definition has to be modified in case one wants to specify another evaluation 
order for expressions, involving the use of the ASM choose construct if some 
non-deterministic choice has to be formulated. For a discussion of such model 
variations we refer to [15] where an ASM model is developed which can be 
instantiated to capture the different expression evaluation strategies in Ada95, 
C, C++, Java, Cj] and Fortran. 

ArgEval = match context{pos) 

0 ^Yield([]) 

(arg , . . . ) ^ pos := arg 

(vail , ■ ■ ■ ,*~valn) — > YiELDUp([waZi, . . . , vain]) 
val , arg . . . ) ^ pos := arg 



Statement Execution Rules. The semantics of static initialization is lan- 
guage dependent and is further discussed below for Java and Cfi. The rules 
for method return in ExegLStmc trigger an abruption upon returning from a 
method. Via the ReturnPropagation submachine defined below, an abrup- 
tion Return or Return(val) due to method return is propagated to the beginning 
of the body of the method one is returning from. There an execution of the sub- 
machine ExitMethod is triggered, which restores the environment of the caller. 
This abruption propagation mechanism allows one an elegant refinement for Lf: , 
where the method exit is subject to the prior execution of so-called finally 
code which may be present in the method. The rule to YiELDUp(Aorm) does 
not capture falling off the method body, but yields up the result of the normal 
execution of the invocation of a method with void return type in an expression 
statement. 

ExecCUStmc = match context(pos) 

StatigInitializer( L) 
return exp ; pos := exp 
return ^val; — > Yielb\Jp{ Re turn (val)) 
return; ^ Yield (Return) 
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ReturnPropagation(L) 

^Norm; ^ Yield\Jp{ N orm) 

The return propagation machine for CjJ is simpler than (in fact part of) that 
for Java due to static differences (including the different use of labels) in the 
two languages. As mentioned above, both machines, instead of transferring the 
control from a return statement directly to the invoker, propagate the return 
abruption up to the starting point of the current method body, from where the 
method is exited. 

RETURNPROPAGATiON(Cjl) = match context{pos) 

Return — > if pos = body{meth) A Empty (frames) then 

ExitMethod( Aorm) 

Return(val) if pos = body(meth) A ^ Empty (frames) then 
ExiTMETHOD(?;aZ) 

ReturnPropagation( Java) = match context(pos) 
lab : Return YieldUp (R etern) 

lab : ^ Return(val) Yield\Jp( R eturn (val)) 

RETURNPROPAGATION(Ctl) 

To complete the return propagation in Java one still has to treat the special 
case of a return from a class initialization method. In [14, Fig. 4.5] this has 
been formulated as part of the StaticInitializer machine, which also realizes 
the condition for the semantics of Java that before initializing a class, all its 
superclasses have to be initialized. To stop the return propagation at the point of 
return from a class initialization, in the case of Java the predicate PropagatesAbr 
has to be refined as follows: 

PropagatesAbr (a) label(a) ^ {LabeledStm, StaticBlock} 

In Cj) the initialization of a class does not trigger the initialization of its direct 
base class, so that STATiclNiTiALiZER(Ctl) is empty. 

StaticInitializer( J ava) = match context(pos) 
static stm —>■ let c = classNm(meth) in 

if c = Object V Initialized(super(c)) then pos := stm 
else lNiTiALiZE(sMper(c)) 
static Return Yiele>\Jp( R eturn) 

The machine ExitMethod, which is the same for Java and for Cfi (modulo 
the submachine FreeLocals), restores the frame of the invoker and passes 
the result value (if any). Upon normal return from a static constructor it also 
updates the typeState of the relevant class as Initialized. We also add a rule 
FreeLocals to free the memory used for local variables and value parameters, 
using an abstract notion FreeMemory of how addresses of local variables and 
value parameters are actually de-allocated.^^ 



12 



Under the assumption of a potentially infinite supply of addresses, which is often 
made when describing the semantics of a programming language, one can dispense 
with FreeLocals. 
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ExiTMETHOD(resMZt) = 

let {oldMeth, oldPos, oldLocals, oldValues) = top{frames) in 
meth •= oldMeth 
pos := oldPos 
locals := oldLocals 
frames := pop (frames) 
if StaticCtor(meth) A result = Norm then 
typeState(type{meth)) := Initialized 
values := oldValues 
else 

values := oldValues 0 {oldPos result} 

FreeLocals 

FreeLocals = 

forall X G LocalVars(meth) U ValueParams(meth) do 
FREEMEMORY(ZocaZs(a;), type(x)) 

For both Java and CjJ, a type c is considered as initialized if its static con- 
structor has terminated normally, as is expressed by the update of typeState(c) 
to Initialized in FxitMethod above. In addition, c is considered as initialized 
already if its static constructor has been invoked, to guarantee that during the 
execution of the static constructor accesses to the fields of c or invocations of 
methods of c do not trigger a new initialization of c. This explains the update 
of typeState(c) to InProgress in the definition of Initialize and the following 
definition of Initialized: 

Initialized (c) typeState(c) = Initialized V typeState(c) = InProgress 

To initialize a class its static constructor is invoked (denoted <clinit> in 
Java and .cctor in CjJ). All static fields of the class are initialized with their 
default value. The typeState of the class is updated to prevent further invocations 
of Initialize(c) during the execution of the static constructor of c. The macro 
will be further refined in to account for exceptions during an initialization. 

Initialize(c) = 
if typeState(c) = Linked then 
typeState(c) := InProgress 
forall / G staticFields(c) do 

let t = type(c::f) in WRiTEMEM( 5 Zo&aZs(c::/), t, defaultValue(t)) 
InvokeMethod(c:: . cctor, []) 

With respect to the execution of initializers of static class fields the FCMA 
standard [7, §17.4.5.1] for Cft says that the static field initializers of a class cor- 
respond to a sequence of assignments that are executed in the textual order in 
which they appear in the class declaration. If a static constructor exists in the 
class, execution of the static field initializers occurs immediately prior to execut- 
ing that static constructor. Otherwise, the static field initializers are executed at 
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an implementation- dependent time prior to the first use of a static field of that 
class. 

Our definitions above for CU express the decision taken by Microsoft’s cur- 
rent CjJ compiler, which in the second case creates a static constructor and 
adds the bef oref ieldinit flag to the class. If one wants to reflect also the 
non-determinism suggested by the ECMA formulation, one can formalize the 
implementation-dependent initialization of bef oref ieldinit types by the fol- 
lowing ruled^ 

ExecCHc = choose x € {0, 1} do 

if a; = 0 then {ExecCUExpc, ExecCHStmc} 

if a; = 1 then 

choose c G Class with BeforeFieldInit{c) A -^Initialized{c) do 
Initialize(c) 



4 Extension of by Object-Oriented Features 

In this section we extend Lc to an object-oriented language Lo by adding ob- 
jects for class instances, formally represented as elements of a new set Ref of 
references. The extension provides new expressions, namely for instance fields, 
instance methods and constructors, and for the dynamic creation of new class 
instances. The inheritance mechanism we consider supports overriding and over- 
loading of methods, dynamic type checks, and type casts. We skip the (via 
syntactical differences partly language-specific) treatment of arrays; their de- 
scription for Java and Cf can be found in [14,4]. The interpreter ExecLo is 
defined as a refinement of ExecLc, obtained from the latter by extending its 
universes, functions, macros and rules to make them work also for the new ex- 
pressions. 

4.1 Static Semantics of Lo 

The first extension concerns the sets Exp, Vexp, Sexp where the new reference 
types appear, ‘null’ denotes an empty reference, ‘this’ is interpreted as the 
current reference. A RefExp is an expression of a reference type. We use ‘pred’ 
to denote a predecessor class, in Java written ‘super’ and in Ctl ‘base’. 

Exp ::=...[ ‘null’ | ‘this’ | Exp ‘ . ’ Field \ ‘ (’ Type ‘)’ Exp \ SpecificExp{L) 

Vexp ::= ... | Vexp ‘ . ’ Field \ RefExp ‘ . ’ Field \ ‘pred’ ‘ . ’ Field 

Sexp ::=...[ ‘new’ Type ( [Args] ) | Exp ‘ . ’ Meth ( [Args] ) 

I ‘pred’ ‘ . ’ Meth ( [Args] ) 

This is discussed in detail in [9]. The reader finds there also a detection of further 
class initialization features that are missing in the ECMA specification, related to 
the definition of when a static class constructor has to be executed and to the 
initialization of structs. 




62 



E. Borger and R.F. Stark 



The specific expressions of Javax and Cjlx are extended by specific object- 
oriented expressions of these languages as follows: 

SpecificExp{Java) ::= . . . \ Exp ‘instanceof ’ Type 
SpecificExpiG't) | ‘typeof’ ‘ (’ RetType ‘)’ | Exp ‘is’ Type 

I Exp ‘as’ Ref Type 



Type Structure. To be able to explain by variations of our interpreter ExecL 
the major differences between Java and CjJ, we need to mention here some of the 
major differences in the type structure underlying the two languages. For effi- 
ciency reasons CjJ distinguishes between value types and reference types. When 
a compiler encounters the declaration of a variable of value type, it directly 
allocates the memory to that variable, whereas for declarations of variables of 
reference type it creates a pointer to an object on the heap. A mediation between 
the two types is provided, known under the name of boxing, to convert values 
into references, and of an inverse operation called unboxing. At the level of Lq , 
besides the new type of References present in both languages, Ctl also introduces 
so-called Struct types, a value-type restricted version of classes, to circumvent 
the overhead associated with class instances. 

Therefore, to be prepared to instantiate our ^^interpreter to an interpreter 
for both Java and Cjl, the domain of values of Lx is extended to contain not 
only References (with a special value null G Ref to denote a null reference), as 
would suffice for interpreting Java©, but also struct values. For the case of CjJ we 
assume furthermore references to be different from addresses, i.e., RefnAdr = 0. 

Value = Simple Value U Adr U Ref U Struct 

The set Struct of struct values can be defined as the set of mappings from 
StructType:: Eield to Value. The value of an instance field of a value of struct 
type T can then be extracted by applying the map to the field name, i.e., 
structField{val, T,f) = val{f). We abstract from the implementation-dependent 
layout of structs and objects and use a function 

fieldAdr-. {Adr U Ref) x Type::Field Adr 

to record addresses of fields. This function is assumed to satisfy the following 
properties, where the static function 

instanccFields: Type Powerset{Type:: Field) 

yields the set of instance fields of any given type t; if t is a class type, it includes 
the fields declared in all pred(ecessor) classes of t: 

■ If t is a struct type, then fieldAdr {adr , t::f) is the address of field / of a value 

of type t stored in mem at address adr. 
m A value of struct type t at address adr occupies the following addresses: 

{fieldAdr {adr , f) \ f G instanccFields {t){ 
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Tvalue type^ 



(preference type^ 




Fig. 2. The classification of types of C# 



■ If runTimeType{ref) is a class type, then fieldAdr{ref , t::f) is the address of 
field t::f of the object referenced by ref and the object represented by ref 
occupies the addresses 

{fieldAdr{ref,f) \ f G instanceFields{c)} 
where c = runTimeType{ref) = c. 

For our language L we do not specify further types. For the sake of illustration 
see Fig. 2 with the extended type classification of Cjl, where the simple types of 
Lx became aliases for struct types. 

Syntax- Tree Information. According to our assumption that the attributed 
syntax tree has exact information, for the formulation of our model we assume 
as result of field and method resolution that each field access has the form T-.:f , 
where / is a field declared in the type T . Similarly, each method call has the 
form T::m(.args) , where m is the signature of a method declared in type T. 
Moreover, for the access of fields and methods via the current instance or the 
predecessor class we know the following: 

■ pred./ in class C has been replaced by this. 5::/, where B is the first 
predecessor class of C where the field / is declared. 

■ pred.miargs') in class C has been replaced by t,hls . Br.M iargs) , where 
B'.'.M is the method signature of the method selected by the compiler (the 
set of applicable methods is constructed starting in the pred class of C). 
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■ If / is a field, then / has been replaced by this. T::f, where / is declared 
in T. 

Instance creation expressions are treated like ordinary method invocations, 
splitting an instance creation expression into a creation part and an invocation 
of an instance constructor. To make the splitting correctly reflect the intended 
meaning of new T::M (args), we assume in our model without loss of generality 
that class instance constructors return the value of this.^^ 

■ Let T be a class type. Then the instance creation expression new T::M (args) 
is replaced by new T . T::M (args) . 

Also for constructors of structs we assume that they return the value of this. 
For instance constructors of structs one has to reflect that in addition they need 
an address for this. Let 5” be a struct type. Then: 

■ vexp = new S::M (args) has been replaced by vexp ,S::M (args) . This reflects 
that such a new triggers no object creation or memory allocation since structs 
get their memory allocated at declaration time. 

■ Other occurrences of new S::M (args) have been replaced by x . S::M (args) , 
where a; is a new temporary local variable of type S. 

For automatic boxing we have: 

■ vexp = exp is replaced by vexp = (T)exp if type(exp) is a value type, 
T = type{vexp) and T is a reference type. In this case we must have 
type(exp) ^ T, where ^ denotes the here not furthermore specified sub- 
type relation (standard implicit conversion) resulting from the inheritance 
and the ‘implements’ relation between classes and interfaces. 

■ arg is replaced by (T)arg if type(arg) is a value type, the selected method 
expects an argument of type T and T is a reference type. In this case we 
must have type (arg) ^ T. 

4.2 Dynamic Semantics of Lo 

Two new dynamic functions are needed to keep track of the runTimeType: Ref —>■ 
Type of references and of the type object typeObj : RetType Ref of a given 
type, where RetType ::= Type \ ‘void’. The memory function is extended to store 
also references: 

mem: Adr SimpleValue U Ref U { Undef} 

For boxing we need a dynamic function value Adr: Ref —>■ Adr to record 
the address of a value in a box. If runTimeType (ref) is a value type, then 
valueAdr(ref) is the address of the struct value stored in the box. 



The result of a constructor invocation with new is the newly created object, which 
is stored in the local environment as value for this. Therefore one can equivalently 
refine the macro ExitMethod for constructors to pass the value of this upon 
returning from a constructor, see [14, pg. 82]. 
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The this reference is treated as first parameter with index zero. It is passed 
by value in instance methods of classes. It is passed by reference in struct meth- 
ods, as an out paramter in constructors and as a ref paramter in instance 
methods. 

For the refinement of the ExecL c transition rules it suffices to add the new 
machine ExecLExpo for evaluating the new expressions, since Lo introduces 
no new statements. 

ExecL o = 

ExecLExpo 

In ExecLExpq the type cast rule contains three clauses concerning value 
types, which are needed for CjJ but are not present for Java. In fact for Java 
the first RefType subrule suffices, the one where both the declared type and the 
target type are compatible reference types and the reference is passed through. 
FieldExpo contains the rules for field access and assignment as needed for Cft, 
where for Java the additional access rule for value types is not needed (and the 
macros for getting and setting field values are simplified correspondingly). Newq 
differs for Java and CjJ, reflecting the different scheduling for the initialization, 
as specified below. The rules for instance method invocation are the same for 
Java and CD modulo different definitions for the macro Invoke and except that 
for CjJ an additional clause is needed for StructValueInvocations. A struct value 
invocation is a method invocation on a struct value which is not stored in a 
variable. For such struct values a temporary storage area (called ‘home’) has to 
be created which is passed in the invocation as value of this. The submachine 
SpecificExpo is specified below for Java and CjJ. 

ExecLExpo = match context{pos) 
null — > YiELD^null) 
this ^ YiELDlNDiRECT(ZocoZs(this)) 

(t) exp pos := exp 
(t)^val 

if type(pos) € RefType then 

if t G RefType A (val = null V runTimeType{val) ^ f) then 
YieldUp(woZ) // pass reference through 
if t G ValueType A val null A t = runTimeType{val) then 
// un-box a copy of the value 
YiELD\Jp{memValue{valueAdr{val), t)) 
if type(pos) G ValueType then 

if t = type(pos) then YiELDUp(taZ) // compile-time identity 
if t G RefType then YiELD\JpBox{type{pos) , val) / / box value 
FieldExpo 
Newo 

exp . T::M (args) pos := exp 
*’val . T ::M (args) 
pos := (args) 
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if StructValueInvocation{up{pos)) then 

let adr = new{Adr, type(pos)) in // create home for struct value 
WRiTEMEM(o(ir, type{pos),val) 
values (pos) := adr 

val .TwM*’ ivals) lNVOKE(uaZ, T::M, vafe) 

SpecificExpo 

The following definition formalizes that a struct value invocation is a method 
invocation on a struct value which is not stored in a variable. 

StructValueInvocation{exp . T::M iargs)) 
type (exp) G StructType A exp ^ Vexp 

The rules for instance field access and assignment in FieldExpq are equiva- 
lent for Java and CU modulo two differences. The first difference comes through 
the different definitions for the macro SetField explained below. The second 
difference consists of the fact that Cjl needs the struct type clause formulated 
below (in the second rule for field access), which is not needed for Java.^® We 
use type{exp = type{t::f). 

FieldExpo = match context{pos) 
exp .t::f pos := exp 

*'val. t::f if type (pos) G ValueType A val ^ Adr then 

YieiaAJ i>{structField{val, type(pos), t::f)) 
elseif val yf null then 

YiELDUPlNDiRECT(/ieW^(ir(tJaZ, t::f)) 

expi . t::f = exp 2 — > pos := expi 

*'val .t::f = exp pos := exp 

vail -t::f = val^ if vak yf null then 

SETFiELD(uaZi, t::f , vah) 

YmhD\]¥{val2) 

The different schedules for the initialization of classes in Java and Cj) appear 
in the different definitions for their submachines Newq and Invoke. When 
creating a new class instance, Java checks whether the class is initialized. If 
not, it initializes the class. Otherwise it does what also the machine Newo(CS) 
does, namely it creates a new class instance on the heap, initializing all in- 
stance fields with their default values. See below for the detailed definition of 
HeapInit. 

As in most parts of this paper, we disregard merely notational differences between 
the two models, here the fact that due to the presence of both memory addresses 
and values, the CUo model uses the machine YlELDUplNDlRECT(/ie/dTdr(t)a/, twf)) 
where the Javao model has the simpler update YmiAi\]p{getField{val, 
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Newo{Jo.vo,) = match context{pos) 
new c ^ if Initialized{c) then 

let ref = new {Ref , c) in 
HEAPlNiT(re/, c) 

Yield (re/) 
else Initialize(c) 

NEWo(Cjl) = match context{pos) 
new c ^ let ref = new {Ref , c) in 
runTimeType{ref) := c 
forall / G instanceFields{c) do 

let adr = fieldAdr{ref ,f) and t = type{f) in 
WRiTEMEM(arfr, t, defaultValue{t)) 

YiELD(re/) 

The Invoke rule for Java is paraphrased from [14, Fig. 5.2]. The compile- 
time computable static function lookup yields the class where the given method 
specification is defined in the class hierarchy, depending on the run-time type of 
the given reference. 

lNVOKE(raZ, T::M , vals){Java) = 
let S = case callKind{up{pos)) of 

Virtual lookup{runTimeType{val) , T::M) 

Super — > lookup{super{classNm{meth)), T::M) 

Special T 

InvokeMethod(5'::M, [val]vals) 

CH performs the initialization test only in the very moment of performing 
Invoke, after the evaluation of the constructor arguments. Thus the invocation 
of an instance constructor of a class may trigger the class initialization (see the 
detailed analysis in [9]). The split into virtual and non- virtual method calls is 
reflected in the submachine InvokeInstance. 

lNVOKE(uaZ, T::M,vals){Ci) = 

if InstanceCtor{M) A triggerInit{T) then Initialize( T) 
elseif val null then InvokeInstance( T ::M, val, vals) 

InvokeInstance{T::M , val, vals) = 

if callKind{T::M) = Virtual then // indirect call, val G Ref 

let S = lookup {runTimeType{val), T::M) in 
let this = if 5 G StructType then valueAdr{val) else val in 
InvokeMethod(5'::M, [this] ■ vals) 

if callKind{T::M) = NonVirtual then // direct call, val G Adr U Ref 
InvokeMethod( T::M, [val] ■ vals) 

The machines SpecificExpo define the semantics of the language-specific 
expressions listed above, which are all related to type checking. 
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SPECiFicExPo(/at'a) = match context{pos) 
exp instcinceof t pos := exp 

*~val instanceof t YiELDUp(uaZ ^ null A runTimeType{val) ^ t) 

SPECiFicExPo(Cjl) contains SPFCiFicExPo(/at'a) as a submachine (modulo 
notational differences), namely consisting of the first and the third rule for the is- 
instruction. In addition we have rules to yield the type of an object and for type 
conversion between compatible types, which needs a new macro YieldUpBox 
defined below for yielding the reference of a newly created box. 

SPECiFicExPo(Cjl) = match context{pos) 
typeof(t) ^ YiELD{typeObj{t)) 
exp is t ^ pos := exp 
*~val is t ^ if type(pos) € ValueType then 

YiELD\Jp{type{pos) ^ t) j j compile-time property 
else 

YiELDUp(uaZ yf null A runTimeType{val) ^ t) 
exp as t ^ pos := exp 
*'val as t ^ if type{pos) G ValueType then 

YiELDUpBox(t?/pe(pos), val) / / box a copy of the value 
elseif {val yf null A runTimeType{val) ^ t) then 
YiELDUp(uaZ) // pass reference through 
else YiELDUp(nMZZ) / / convert to null reference 

Memory Refinement. Due to the appearance of reference (and in Cft also 
struct) types an extension of the memory notion is needed. To model the dynamic 
state of objects, storage is needed for all instance variables and to record to which 
class an object belongs. The model for Javao in [14] provides for this reason a 
dynamic function heap: Ref —>■ Heap to record every class instance together with 
the values of its fields. Heap can be considered as an abstract set of elements 
of form Ob ject{t, fields), where fields is a map associating a value with each 
field in instanceFields{f) . One can then define two simple macros SetField and 
GetField to manipulate references on this abstract heap as follows (where 0 
denotes adding a new (argument, value)-pair to a function, or overwriting an 
existing value by a new one): 

GETFiELD(re/, /)(Jaua) = case heap{ref) of 
Qhject{t, fields) ^ fields {f) 

SETFiELD{ref ,f ,val){Java) = let Object(t, /leWs) = heap{ref) in 
heap{ref) := Ohject{t, fields 0 {(/,vaZ)}) 

For modeling CSo a further refinement of both reading from and writing to 
memory is needed, due to the presence of struct types and call-by-reference. The 
notion of reading from the memory is refined by extending the simple equation 
memValue{adr,t) = mem{adr) of Cjlx to fit also struct types, in addition to 
reference types. This is done by the following simultaneous recursive definition 
of memValue and getField along the given struct type. 




Exploiting Abstraction for Specification Reuse 



69 



memValue{adr,t) = 

if f G SimpleType U Ref Type then mem{adr) 
elseif t G StructType then 

{/ ^ getField{adr , t::f) \ f G instanceFields{t)} 

getField{adr , t::f) = memValue{fieldAdr{adr , type{t::f)) 

Similarly, writing to memory is refined from 

WriteMem ( adr, t, val) = mem{adr) := val 
in Cttx, recursively together with SetField along the given struct type: 

WRiTEMEM(adr, t, val) = 

if f G SimpleType U Ref Type then mem{adr) := val 
elseif t G StructType then 

forall / G instanceFields{f) do SETFiELD(odr, f::/, waZ(/)) 

SETFiELD(adr, t::f, val) = WRiTEMEM{fieldAdr{adr, t::f), type{t::f), val) 

The notion of AddressPos from Cfc is refined to include also lvalue nodes of 
StructType, so that address positions are of the following form: 

ref □, out □, □++, □ — , □ op= exp, □./, O .m(args) 

AddressPos(a) FirstChild{a) A 

label{up{a)) G {ref, out, ++, — } U Aop V 
{label{up{a)) = ’ A A a € Vexp A type{a) G StructType) 

YieldUpBox creates a box for a given value of a given type and returns its 
reference. The run-time type of a reference to a boxed value of struct type t is 
defined to be t. The struct is copied in both cases, when it is boxed and when 
it is un-boxed. 

YiELDUpBox(t, val) = let ref = new(Ref) and adr = new{Adr, t) in 
runTimeType{ref) := t 
valueAdr{ref) := adr 
WRiTEMEM(odr, t, val) 

YiELDUp(re/) 

5 Extension of by Exceptions 

Lx extends Lq with exceptions, designed to provide support for recovering from 
abnormal situations, separating normal program code from exception handling 
code. When an Z^program violates certain semantic constraints at run-time, the 
interpreter signals this as an exception. The control is transferred, from the point 
where the exception occurred, to a point that can be specified by the program- 
mer. An exception is said to be thrown from the point where it occurred, and it 
is said to be caught at the point to which control is transferred. The model for Lg 




70 



E. Borger and R.F. Stark 



makes explicit how jump statements from Lx, return statements from Lc and the 
initialization of classes from Lq interact with catching and handling exceptions. 

Technically, exceptions are represented as objects of predefined system excep- 
tion classes (in Java java. laing.Throwable and in Cf System. Exception) or of 
user-defined application exception classes. Once ‘thrown’, these objects trigger 
an abruption of the normal program execution to ‘catch’ the exception - in case 
it is compatible with one of the exception classes appearing in the program in an 
enclosing try-catch- finally statement. Optional finally statements are guaranteed 
to be executed independently of whether the try statement completes normally 
or is abrupted. We consider run-time exceptions, which correspond to invalid 
operations violating the semantic constraints of the language (like an attempt 
to divide by zero or to index an array outside its bounds) and user-defined ex- 
ceptions. We do not treat errors which are failures detected by the underlying 
virtual machine machine (JVM or CLR). 

5.1 Static Semantics of 

For the refinement of ExecLo by exceptions, it suffices to extend the static 
semantics and to add the new rules for exception handling. The set of statements 
is extended by throw and try-catch-finally statements as defined by he following 
grammar (where the throw statement without expression and so-called general 
catch clauses of form catch block are present only in CD, not in Java): 

Stm ‘throw’ Exp ‘ ; ’ | ‘throw’ ‘ ; ’ 

I ‘try’ Block {Catch} [‘catch’ Block] [‘finally’ Block] 

Catch ::= ‘catch’ ‘(’ ClassType [Loc] ‘)’ Block 

Various static constraints are imposed on try-catch-finally statements in L- 
programs, like the following ones that we need to explain the correctness of the 
transition rules below: 

■ every try-catch-finally statement contains at least one catch clause, general 
catch clause, or finally block 

■ the exception classes in a catch clause appear there in a non-decreasing type 
order, more precisely for every try-catch statement 

try block catch (Ei x\) blocki . . . catch (i?„ x„) blockn 
holds: i < j Ej Ei 

Some static constraints on try-catch-finally statements are language-specific. 
We only list the following three specific constraints of CD which will be needed 
to justify the correctness of the transition rules below. 

■ no return statements are allowed in finally blocks 

■ a breah, continue, or goto statement is not allowed to jump out of a finally 
block 

■ a throw statement without expression is only allowed in catch blocks 
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To simplify the exposition we assume that general catch clauses ‘catch block' 
are replaced at compile-time by ‘catch (Object x ) block' with a new variable x 
and that try-catch-finally statements have been reduced to try-catch and try- 
finally statements, e.g., as follows: 



try TryBlock 

catch {El x\) CatchBlocki 

catch (En x„) CatchBlockn 
finally EinallyBlock 



try { 

try TryBlock 

catch (El x\) CatchBlocki 

catch (En Xn) CatchBlockn 
} finally EinallyBlock 



Since throwing an exception completes the computation of an expression or 
a statement abruptly, we introduce into the model a new type of reasons of 
abruptions and type states, namely references Exc(Ref) to an exception object. 
Due to the presence of throw statements without expression in Cjl, also a stack 
of references is needed to record exceptions which are to be re-thrown. 

Abr = • . • I Exc(Ref), TypeState = . • . | Exc(Ref), excStack: List(Ref) 



5.2 Dynamic Semantics of Lg 

The transition rules for ExecL^; are defined by adding two submachines to 
ExecLo. The first one provides the rules for handling the exceptions which 
may occur during the evaluation of expressions, the second one describes the 
meaning of the new throw and try-catch-finally statements. 

ExecLb = 

ExecLExp^; 

ExecLStmb 



Expression Evaluation Rules. ExecLExp^; contains rules for each of the 
forms of run-time exceptions foreseen by L. We give here some characteristic 
examples and group them for the ease of presentation into parallel submachines 
by the form of expression they are related to, namely for arithmetical exceptions 
and for those related to cast and reference expressions. The notion of FailUp we 
use is supposed to execute the code throw new E () at the parent position, which 
allocates a new object for the exception and throws the exception (whereby the 
execution of the corresponding finally code starts, if there is any, together with 
the search for the appropriate exception handler. Therefore one can define the 
macro by invoking an internal method ThrowE with that effect for each of the 
exception classes E used as parameter of FailUp. 

In the formulation of the following rules we use the exception class names 
from Cjl, which are often slightly different from those of Java. A binary expression 
throws an arithmetical exception, if the operator is an integer division or remain- 
der operator and the right operand is 0. The overflow-clause for unary or binary 
operators is expressed using the above defined Checked predicate from Ctl. 
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ExecLExpb = match context{pos) 

vail bop *’val2 if DivisionByZero{bop,val2) then 

FAlLUp(DivideByZeroException) 
elseif DecimalOverflow{bop, vali, vah)^ 

{Checked{pos) A Overflow{bop, vali, vah)) 
then FAlLUp(Overf lowException) 
uop *~val if Checked{pos) A Overflow (uop,val) then 
FAlLUp(Overf lowException) 

CastExceptions 

NullRefExceptions 

In Java, a reference type cast expression throws a ClassCastException, if 
the value of the direct subexpression is neither null nor compatible with the 
required type. This is the first clause in the rule below which is formulated 
for Cj), where additional clauses appear due to value types. 

CastExceptions = match context{pos) 

{t)*'val 

if type(pos) € RefType then 

if f G RefType A val null A runTimeType{val) t then 
FailUp( I nvalidCastExcept ion) 

if f G ValueType then // attempt to unbox 

if val = null then FAlLUp(NullRef erenceException) 
elseif t ^ runTimeType(val) then 
FAlLUp(lnvalidCastException) 
if type(pos) G SimpleType A t G SimpleType A 

Checked{pos) A Overflow{t, val) 
then FAlLUp(Overf lowException) 

An instance target expression throws a NullRef erenceException, if the 
operand is null (in Java a NullPointerException). 

NullRefExceptions = match context(pos) 

^ref .t::f if ref = null then 

FailU P (NullRef er enceExcept i on) 
ref . t::f = *'val if ref = null then 

FailU p (N ullRef er enceExcept i on) 
ref . T ::M (^vals) — > if ref = null then 

FailU p (N ullRef er enceExcept i on) 

Statement Execution Rules. The statement execution submachine splits 
naturally into submachines for throw, try-catch, try-finally statements and a 
rule for the propagation of an exception (from the root position of a method 
body) to the method caller. We formulate the machine below for CD and then 
explain its simplification for the case of Java (essentially obtainable by deleting 
every exception-stack-related feature). 

When the exception value ref of a throw statement has been computed, 
and if it turns out to be null, a NullRef erenceException is reported to the 
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enclosing phrase using FailUp, which allocates a new object for the exception 
and throws the exception. If the exception value ref of a throw statement is 
not null, the abruption Exc{ref) is passed up to the (position of the) throw 
statement, thereby abrupting the control flow with the computed exception as 
reason. The semantics of the parameterless throw; statement is explained as 
throwing the top element of the exception stack excStack. 

Upon normal completion of a try statement, the machine passes the con- 
trol to the parent statement, whereas upon abrupted completion the machine 
attempts to catch the exception by one of the catch clauses. The catching con- 
dition is the compatibility of the class of the exception with one of the catcher 
classes. If the catching fails, the exception is passed to the parent statement, as is 
every other abruption which was propagated up from within the try statement. 
Otherwise the control is passed to the execution of the relevant catch statement, 
recording the current exception object in the corresponding local variable and 
pushing it on the exception stack (thus recording the last exception in case it 
has to be re-thrown). Upon completion of this catch statement, the machine 
passes the control up and pops the current exception object from the exception 
stack — the result of this statement execution may be normal or abrupted, in the 
latter case the new exception is passed up to the parent statement. No special 
rules are needed for general catch clauses ‘catch block' in try-catch statements, 
due to their compile-time transformation mentioned above. 

For a finally statement, upon normal or abrupted completion of the first 
direct substatement, the control is passed to the execution of the second di- 
rect substatement, the finally statement proper. Upon normal completion of 
this statement, the control is passed up, together with the possible reason of 
abruption, the one which was present when the execution of finally statement 
proper was started, and which in this case has to be resumed after execution of 
the finally statement proper. However, should the execution of this finally 
statement proper abrupt, then this new abruption is passed to the parent state- 
ment and a possible abruption of the try block is discarded. The constraints 
listed above for Cj) restrict the possibilities for exiting a finally block to normal 
completion or triggering an exception, whereas in Java also other abruptions 
may occur here. 

In Java there is an additional rule for passing exceptions when they have 
been propagated to the position directly following a label, namely: 

lab : *’Exc{ref) — > YiELDUp(i?a;c(re/)) 

If the attempt to catch a thrown exception in the current method fails, the 
exception is propagated to the caller using the submachine explained below. 

ExecCDStm^; = match context(pos) 
throw exp ; pos := exp 

throw ^ref; —>■ if ref = null then FAlLUp(NullRef erenceException) 
else YiELDUp(i?a;c(re/)) 

throw; ^ YiELD{Exc{top{excStack))) 
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try block catch (E x) stm ... ^ pos := block 

try *’ Norm catch {E x) stm . . . ^ YiELDUp(A^orm) 
try Exc{ref) catch (i?i x\) stm\ . . . catch (i?„ a;„) ^ 

if 3z G [1 . . n] runTimeType{ref) ^ Ei then 

let j = min{z G [1 . . n] | runTimeType{ref) ^ Ei\ in 
pos := stmj 

excStack := push{ref , excStack) 

WRiTEMEM(Zocafe(a;j), object, ref) 
else YiELDUp(i?a;c(re/)) 

try ^ abr catch(i?i xi) stm\ . . . catch(i?„ a;„) ^ YiELDUp(a&r) 

try Exc(ref) . . . catch( . . . ) ^res 

{excStack := pop{excStack) , YiELDUp(res) 
try tryBlock ftnallj finally Block pos := tryBlock 

try ^res ftnallj finallyBlock pos := finally Block 

try res finally ^Yorm ^ YiELDUp(res) 

try res finally ^ Exc(ref) YiELB\Jp{Exc{ref)) 

PROPAGATEToCALLER(£'a;c(re/)) 

If the attempt to catch a thrown exception in the current method fails, 
the exception is passed by PROPAGATEToCALLER(Exc(ref)) to the invoker of 
this method (if there is some), to continue the search for an exception han- 
dler there. In case an exception was thrown in the static constructor of a type, 
in Cj) its type state is set to that exception to prevent its re-initialization and 
instead to re-throw the old exception object, performed by an extension of 
Initialize(c) by the clause if typeState{c) = Exc{ref) then YiELD(iJa;c(re/)). 
In Java, the corresponding type becomes Unusable, meaning that its initial- 
ization is not possible, which is realized by the additional lNiTiALiZE(c)-clause 
if typeState{c) = Unusable then FAiL(NoClassDefFoundErr). 

PROPAGATEToCALLER(i?a;c(re/)) = match context(pos) 

Exc(ref) 

if pos = body{meth) A ^ Empty (frames) then 

if Static Ctor(meth) then typeState(type{meth)) := Exc(ref) 
ExitMethod (i?a;c (re/ ) ) 

The model ExegJavaStm^; in [14, Fig. 6.2] has the following rule for un- 
caught exceptions in class initializers, which is inserted before the general rule 
PROPAGATEToCALLER(iJa;c(re/)). Java specifies the following strategy for this 
case. If during the execution of a static initializer an exception is thrown, and if 
this is not an Error or one of its subclasses, an ExceptionInInitializerError 
is thrown. If the exception is compatible with Error, then the exception is 
rethrown in the directly preceding method on the frame stack. 

match context(pos) 
static Exc(ref) — > 

if runTimeType(ref) A Error then YiELDUp(i?a;c(re/)) 
else FailUp (E xceptionInInitializerError) 
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An alternative treatment appears in the model ExecCUStm^; in [4] where 
unhandled exceptions in a static constructor are wrapped into an exception of 
type TypelnitializationException by translating the static constructor 

static TO { BlockStatements } 
into 

static T 0 { 

try { BlockStatements } 
catch (Exception e) { 

throw new TypelnitializationExceptionC T , e) ; 

} 

} 

The interpreter for Java^ needs also a refinement of the definition of propa- 
gation of abruptions, to the effect that try statements suspend jump and return 
abruptions for execution of relevant finally code. For CjJ this is not needed due 
to the constraints cited above for finally code in Ctl. As explained above, after the 
execution of this finally code, that abruption will be resumed (unless during 
the f inally code a new abruption did occur which cancels the original one) . 

Propagates Abr (a) 

label{a) ^ {LabeledStm, StaticBlock, TryCatchStm, Try Finally Stm} 



6 Conclusion 

We have defined hierarchically structured components of an interpreter for a 
general object-oriented programming language. In doing this we have identified 
a certain number of static and dynamic parameters and have shown that they 
can be instantiated to obtain an interpreter for Java or Cj). As a by-product this 
pinpoints in a precise and explicit way the main differences the two languages 
have in their dynamic semantics. The work confirms the idea that one can use 
ASMs to define in an accurate way appropriate abstractions to support the 
development of precise patterns for fundamental computational concepts in the 
fields of hardware and software, reusable for design-for-change and useful for 
communicating and teaching design skills. 
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Abstract. This paper exploits design patterns employed in coordinat- 
ing autonomous transport vehicles so as to ease the burden in verifying 
cooperating hybrid systems. The presented verification methodology is 
equally applicable for avionics applications (such as TCAS), train appli- 
cations (such as ETCS), or automotive applications (such as platooning). 
We present a verification rule explicating the essence of employed design 
patters, guaranteeing global safety properties of the kind “a collision will 
never occur”, and whose premises can either be established by off-line 
analysis of the worst-case behavior of the involved traffic agents, or by 
purely local proofs, involving only a single traffic agent. In a companion 
paper we will show, how such local proof obligations can be discharged 
automatically. 



1 Introduction 

Automatic collision avoidance systems form an integral part of ETCS-compatible 
train systems, are appearing or about to appear in cars, and - in the somewhat 
weaker form of only providing recommendations to the pilot - required to be 
installed on any aircraft with more than 30 passengers. The verification of the 
correctness of such collision avoidance system has been studied extensively e.g. 
within the PATH project (see [12]), by Leveson et al. [10], Sastry et al. [17] and 
Lynch et al. [11] for various versions of the TCAS system, or by Peleska et al. 
[6] and Damm et al. [4] for train system applications. Shankar et al presents in 
[12] a general approach of developing such distributed hybrid systems. 

Our paper aims at reducing the complexity of the verification of collision 
avoidance systems. To this end, we explicate typical design approaches for such 
protocols, and cast this into a proof rule reducing the global safety requirement 
“a collision will never occur” to simpler proof tasks, which can either be es- 
tablished off line, involve purely local safety- or real-time properties, or pure 
protocol verification. We illustrate our approach by showing how the correctness 
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of TCAS and a protocol for wireless safe railroad crossings can be established 
by instantiating the proposed verihcation rule. While the methodology as such 
is applicable to any bounded number of agents, we will illustrate our approach 
considering only collision avoidance for two agents. 

The approach centers around the following key design concepts. 

Each traffic agent is equipped with a safety envelope, which is never to be 
entered by another agent. The safety envelope of an agent is an open ball around 
the agent’s current three-dimensional position, with an agent-specihc diameter. 
We allow the extent of the diameter to be mode dependent, thus e.g. enforcing 
different degrees of safety margins during different flight phases, or allowing a 
train to actually cross a railroad crossing if this is in mode “secured” . The global 
safety property we want to prove is, that safety envelopes of agents are always 
kept apart. 

To enforce separation of safety envelopes, the controllers’ coordinating colli- 
sion avoidance offers a choice of corrective actions, or maneuvers. E.g. TCAS dis- 
tinguishes “steep descent”, “descent”, “maintain level”, “climb”, “steep climb”, 
thus restricting the maneuvers to adjustment of the height of the involved air- 
crafts (with future versions expected to also offer lateral avoidance maneuvers) . 
In the train-system application, the maneuvers of the crossing are simple (flash 
light and lower barriers) , and the train will be brought to a complete stop, trying 
hrst the service brake, and resorting to an emergency brake as backup option. 
From the point of view of our methodology, we will assume a set of explicitly 
designated states for such collision avoidance maneuvers, henceforth called cor- 
rective modes. It is the task of the collision-avoidance protocol to select matching 
pairs of corrective modes: the joint effect of the strategies invoked by the chosen 
states ensures, that the agents will pass each other without intruding safety en- 
velopes - a condition, which we refer to as adequacy. E.g. TCAS will never ask 
both aircrafts to climb - the decision of which aircraft should climb, and which 
descend, is taken based on the relative position and the identity of the aircraft 
(to break symmetry, identities are assumed to be totally ordered) . 

A key design aspect of collision avoidance protocols is the proper determina- 
tion of invocation times for corrective maneuvers. Due to the safety criticality of 
the application, such triggering points must be determined taking into account 
the most adversary behavior of traffic agents, within the overall limits stipulated 
by traffic regulation authorities. As an example, triggering a mode switch to en- 
force safe braking of the train must be done in time to allow the train to come 
to a complete stop even when driving the maximal allowed speed for the cur- 
rent track segment, as well as the maximally allowed slope for track segments. 
This in fact simplifies the analysis, because it both requires as well as allows 
to perform the analysis using an over-approximation of the agents’ behavior. 
Conformance to such upper bounds on velocity must be established separately 
- note, that this is a verihcation task local to the agent. We can then use off-line 
analysis based on the over-approximated behavior of the plant and knowledge 
of the corrective maneuvers to determine the need for a mode switch to one of 
the corrective modes. 
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We will show that we can determine off line, which combinations of correc- 
tive states will satisfy the adequacy condition (we call these matching corrective 
states), by exploiting guarantees about invocation time for corrective actions, 
and analyzing the possible evolutions from the plant regions characterized by 
the predicates inducing mode switching, thus reducing the global verification 
of adequacy to the verification, that only matching corrective states are se- 
lected. 

This paper is structured as follows. The next section explicates our mathe- 
matical model of cooperating traffic agents, enriching the well known model of 
cooperating hybrid automata with sufficient structure to perform our analysis. 
The ingredients of our verification methodology are elaborated in Section 3. We 
discuss to which extent the analysis from [11] differs from our decomposition ap- 
proach in Section 4, and perform likewise for the railroad crossing in Section 5. 
We will discuss possible extensions of the methodology in the conclusion. 



2 Model of Cooperating Traffic Agents 

This section introduces our mathematical model of cooperating traffic agents, us- 
ing a variant of communicating hybrid automata from Tomlin et al [16] allowing 
general ordinary differential equations as specifications of continuous evolutions. 

An agent’s controller is typically organized hierarchically. A cooperation layer 
is responsible for the protocol with other agents, allowing each agent to acquire 
approximate knowledge about the state of other agents, and exchanging infor- 
mation on the chosen strategies for collision avoidance. At the lowest level, which 
we will refer to as the reflex layer, basic control laws are provided for all normal 
modes of operations, such as maintaining the speed of the train at a given set 
point. We abstract from the concrete representation of the control laws, assum- 
ing that they can be cast into a set of differential equations, expressing how 
actuators change over time. The state space of the controller is spanned from 
a finite set of discrete modes M and a set of (real- valued) state variables V, 
subsuming sensors and actuators of the controlled plant. We assume a special 
variable id to store the identity of an agent. We explicitly designate a set of 
modes as corrective modes, implementing the control laws for collision avoidance 
maneuvers. E.g. in the TCAS context, this would include the control laws for 
the various degrees of strength for climb, respectively descent maneuvers, or in 
the train system context, the selection of either activating the service brake, or 
the emergency brake. A coordination layer is responsible for mode switching in 
general, and in particular for the selection of the collision avoidance maneuvers, 
by entering the control mode activating the control law associated with the cho- 
sen maneuver. Mode switching can be triggered by communication events, by 
timeouts, and by conditions on the plant state becoming true. We allow to cap- 
ture typical assumptions on discrete and continuous variables to be expressed 
as global invariances or mode invariances. Typical usages of invariants for dis- 
crete modes will relate to the cooperation protocol, as well as the stipulation, 
that corrective maneuvers will be maintained until potentially critical situations 




80 



W. Damm, H. Hungar, and E.-R. Olderog 



have been resolved.^ Typical usages of invariances for continuous variables will 
be the enforcement of regulatory stipulations such as regarding maximal allowed 
speed, or tolerated degrees of acceleration resp. deceleration. 

As to the model of the traffic agent’s plant, we assume, that the set of plant 
variables subsumes the traffic agents space coordinates x, j/, z, its velocity in each 
dimension Vx,Vy,Vz, as well as its acceleration ax, ay, a^ in each dimension, a set 
of actuator variables A, as well as a set of disturbances D. A subset S of the sys- 
tem variables, the sensor variables, are observable by the plant’s controller, which 
in turn can influence the plant by the setting of actuators. We assume that space 
coordinates, velocity, and acceleration are directly observable by the controller. 
For the current version, we consider simple plant models without discrete state 
components.^ The dynamics of the system is specified by giving for each non- 
input system variable an ordinary differential equation, whose right hand side 
may contain all variables of the plant. This includes the standard dependencies 
between acceleration, velocity, and space coordinates. Plant invariances allow to 
place bounds on disturbances. In particular, we will assume for each disturbance 
upper and lower bounds under which the agent is expected to operate. 

A traffic-agent model combines an agent controller with its plant model, us- 
ing standard parallel composition of hybrid automata. Communication between 
these automata is based solely on the actuator and sensor variables shared be- 
tween these. We thus abstract in this paper from noise in sensor readings and 
inaccuracy of actuators when observing resp. controlling its own plant. Note, 
that the parallel composition used is just a standard parallel composition of au- 
tomata, hence we can view a traffic agent model again as a hybrid automaton. 

A distributed traffic system consists of the parallel composition of N traf- 
fic agents. We abstract in this paper from modeling communication channels, 
and assume, that all communication between traffic agents is based on variables 
shared between their controllers, of mode “output” on the one side and of mode 
“input” on the other. As noted before, mode-switches can be initiated by com- 
munication events, which in this setting is expressed by allowing as trigger to 
test for a condition involving communication variables to become true. We make 
the simplifying assumption, that the variables shared between traffic-agent con- 
trollers include the sensor variables for its coordinates and its speed, as well 
as the identity of the controllers. It is straightforward to extend our approach 
to message-passing based information and accordingly delayed knowledge about 
the other agent’s whereabouts, by interpolating from the last known readings, 
using worst-case bounds dictated by regulations to safely over-approximate the 
actual readings. 



^ The TCAS protocol actually allows to withdraw a given recommendation in re- 
stricted situations, complicating the analysis, see [11]. The above assumption indeed 
eases the off-line analysis required in our approach, but is not inherent. We leave it 
to a later paper to consider more flexible strategies. 

^ In the formal development, we view a plant as a hybrid automaton with a single 
state and no discrete transitions. 
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Since a distributed traffic system is again just built by parallel composition of 
hybrid automata, we can safely identify it with the well-defined hybrid automa- 
ton resulting from the parallel composition of its agents. We can thus focus the 
remainder of this chapter on defining a sufficiently rich class of hybrid automata 
offering all constructs elaborated above for the agents controller and its plant, 
and closed under parallel composition. 

Definition 1 (Hybrid Automaton). A hybrid automaton is a tuple 
HA = (M, V,R‘^,R‘=,mo,e) 
where 

~ M is a finite set of modes, 

— V is a real-valued set of variables, partitioned into input, local and output 
variables, respectively: 

v= V^UV^^U v°, 

~ mo is the initial mode, 

— O associates with each mode m a local invariant 0{m) (a quantifier free 
boolean formula over V ), 

— R‘^ is the discrete transition relation with transitions (m, | (fi,A,m'), also 

written as m m' , where 

• m,m' G M , 

• A is a (possibly empty) set of (disjoint) assignments of the form v := Cy 
with V G U V° and Cy an expression over V , 

• the trigger ) (p is the event that a quantifier-free boolean formula (p over 

V becomes true. 

— R‘^ is the continuous transition relation associating with each mode m and 
each non-input variable v an expression R'^{m){v) over V . 

Intuitively, R'^ thus defines for mode m and each v the differential equation 

V = R‘^{m){v) 

governing the evolution of v while HA is in mode m. □ 

Additionally we require of the discrete transition relation, that the execution 
of one transition does not immediately enable a further transition. 

Definition 2 (Transition Separation). Let a : V ^ be a valuation of the 
variables V. Then A{a) denotes the update of a according to the assignments in 
A, i.e. 

y V & V : {3 Cy : V := Cy G A) A{a){v) = cr(e.„) 

A ^(3 Cy : V := Cy G A) =G- A{a){v) = cr(v). 

The discrete transitions in a hybrid automaton are separated, if for any two 
transitions (mi, | pi,A\, mf) and (m 2 , t T 2 ,A 2 , rnlf) with m{ = m 2 it holds that 

Vcr:T^K: {a \= pi =P A\{a) ^ p2)- 
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Separation implies that at any given point in time during a run, at most one 
discrete transition fires. I.e., our models have dense time, not superdense time, 
where a sequence of discrete transitions is permitted to fire at one instant in time. 

Discrete variables may be included into hybrid automata according to our 
definition via an embedding of their value domain into the reals, and associating 
a derivation of constantly zero to them (locals and outputs). Timeouts are easily 
coded via explicit local timer variables with a derivative in { — 1, 0, 1}, as required 
respectively. 

Note, that indeed this general model subsumes both controller and plant mod- 
els, by choosing the set of variables appropriately and enforcing certain modeling 
restrictions. For our plant models, we require the absence of discrete transitions. 
This entails in particular, that plant variables only evolve continuously, and can- 
not be changed by discrete jumps. This is convenient for the formulation of our 
approach but not essential. 

We will in the definition of runs of a hybrid automaton interpret all transi- 
tions as urgent, i.e. a mode will be left as soon as the triggering event occurs. 
This can either be the expiration of a time-out, or a condition on e.g. the plant 
sensors becoming true. Valid runs also avoid Zeno behavior and time-blocks, i.e. 
each run provides a valuation for each positive point in time. We did not take 
provisions to ensure the existence of such a run, nor the property that each ini- 
tial behavior segment can be extended to a full run. Such might be added via 
adequate modeling guidelines (e.g. by including the negation of an invariant as 
trigger condition on some transition leaving the mode). As these properties are 
not essential to the purpose of this paper we left them out. 

We now give the formal definition of runs of a hybrid automaton HA. To this 
end we consider continuous time and let Time = K>o. Further on, we use the 
notation 

previous{v , t) = lim„^t({)(M)) 

for some v : Time — > K and 0 < t G Time. Satisfaction of a condition containing 
previous entails that the respective limes does exist. ^ 

Definition 3 (Runs of a Hybrid Automaton). A tuple of trajectories 

7T = (m, (f))„g v) , with 
m : Time —>■ M 
V : Time ^ K, v G V 

capturing the evolution of modes and valuations of continuous variables is called 
a run of HA iff 

3 G Time"^ : tq = 0 A V z : < r^+i, 

a strictly increasing sequence of discrete switching times s.t. 

® In fact, our definition of a rnn implies that these limits do exist for all local and 
output variables in any run. 
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1. non-Zeno 

y t € Time 3 i : t < Ti 

2. mode switching times 

y i y t G [Ti,Ti+i) : rh{t) = rh{Ti). 



3. continuous evolution 



y i y t e [Ti,Ti+i) y V G V : 

= R‘^{m{n))[w{t)/w \ w e V] 
at 

4- invariants 

y t G Time : (A v. v{t)) \= 0{m{t)), 

5. urgency 

y i y t G [Ti,Ti+i) V (m, t (fi, A, m') G R’^ : 
m{t) = m {\ V. v{t)) ^ ip 

6. discrete transition firing 

V i : m(ri+i) = m{Ti) A (y v G \J V° \ u(ri+i) = previous{v{Ti+i)) 

V 

3 {mA p,A,m') G R‘^ : 
m{Ti) = m A m(ri+i) = m' 

A 3 tr G V ^ M : 

(V V G \J V° \ a(v) = previous(v , Ti+i) 

A a \= (p 

A V V G V‘ : v{Ti+i) = a{v) 

A V V G U V° : v{n+i) = A{a){v) 

The time sequence identifies the points in time, at which mode- 

switches may occur, which is expressed in Clause (2). Only at those points dis- 
crete transitions (having a noticeable effect on the state) may be taken. On the 
other hand, it is not required that any transition fires at some point Ti, which 
permits to cover behaviors with a finite number of discrete switches within the 
framework above. Our simple plant models with only one mode provide exam- 
ples. As usual, we exclude non-zeno behavior (in Clause (1)). As a consequence 
of the requirement of transition separation, after each discrete transition some 
time must elapse before the next one can fire. Clause (4) requires, for each mode, 
the valuation of continuous variables to meet the local invariant while staying 
in this mode. Clause (3) forces all local and output variables (whose dynamics 
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is constrained by the set of differential equations associated with this mode) to 
actually obey their respective equation. Clause (5) forces a discrete transition to 
fire when its trigger condition becomes true. The effect of a discrete transition 
is described by Clause (6). Whenever a discrete transition is taken, local and 
output variables may be assigned new values, obtained by evaluating the right- 
hand side of the respective assignment using the previous value of locals and 
outputs and the current values of the input. If there is no such assignment, the 
variable maintains its previous value, which is determined by taking the limit of 
the trajectory of the variable as t converges to the switching time Ti+i. Values 
of inputs may change arbitrarily. They are not restricted by the clauses, other 
that they obey mode invariants and contribute to the satisfaction of discrete 
transitions when those fire. 

The parallel composition of two such hybrid automata HAi and HA2 pre- 
supposes the typical disjointness criteria for modes, local variables, and output 
variables. Output variables of HAi which are at the same time input variables of 
HA 2 , and vice versa, establish communication channels with instantaneous com- 
munication. Those variables establishing communication channels become local 
variables of HAi |j HA 2 (in addition to the local variables of HAi and HA 2 ), for 
other variable sets we simply take the union of those not involved in communi- 
cation. Modes of HAi |j HA 2 are the pairs of modes of the component automata. 
One may define the set of runs of HA as those tuples of trajectories which project 
to runs of HAi and HA2, respectively. It is not always possible to give a hybrid 
automaton for HAi || HA2, because of problems with cycles of instantaneous 
communications. Therefore, we impose the following additional condition on the 
composability of hybrid automata. 

Definition 4 (Composable Hybrid Automata). Let two hybrid automata 
HAi, * = 1)2, with discrete transition relations Rf , z = 1,2, he given. For a 
pair of transitions Si = {mi,'[ tfi,Ai,m'i) G Rf , z = 1,2, the transition si is 
unaffected by S 2 , if each variable for which there is an assignment in A 2 appears 
neither in ipi nor in A\ (on any of the right-hand sides). 

The two transition relations are composable, if for each pair of transitions 
Si G Rf, z = 1,2, either si is unaffected by S 2 or vice versa. 

Composability establishes essentially a direction on instantaneous communi- 
cations - communications may have an immediate effect on the output and thus 
the partner automaton, but they must not immediately influence the originator 
of the information. Assuming composability, the rest of the construction of the 
parallel composition automaton is rather standard. 

For a mode {mi, m2), the associated invariant condition is the conjunction 
of the invariance conditions associated with mi and m 2 . Similarly, the set of 
differential equations governing the continuous evolution while in mode {mi, m 2 ) 
is obtained by simply conjoining the set of differential equations attached to mi 
and m2, respectively - note that the disjointness conditions on variables assure, 
that this yields a consistent set of differential equations. Finally, the discrete 
transition relation consists of the following transitions: 
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1. A Ai{(p 2 ),Ai U ^ 1 (^ 2 ), {m[, m^)) 

for each pair of transitions Si = {nii, | (fii, Ai, m[) € Rf, i = 1,2 where Si is 
unaffected by S 2 , 

2. {{mi,m 2 ),(pi /\{^Ai{(fi 2 ) \ (fi 2 trigger in R^},Ai,{m[, m 2 )) 
for each (mi, t <fi,A\, m[) G Rf, and 

3. transitions of the forms (1) and (2) with the role of HAi and HA 2 inter- 
changed, 

where 

1. A{ip) denotes the substitution into ip of e„ for v for each assignment v := 
By G A, and 

2. ^ 1 (^ 2 ) denotes the substitution of the assignments of Ai into the right-hand 
terms of A 2 - 

Composability ensures that the simultaneous transitions of Clause (1) indeed 
capture the combined effect of both transitions. The separation of transitions in 
the resulting automaton is inherited from separation in the component automata 
by the way single-automata transitions (Clause (2)) are embedded. 

In the sequel, we will analyse two-agent systems 

(C'i||Pi)||(C'2||P2), 

consisting of a controller and a plant automaton each. We will establish a proof 
rule allowing to reduce the global requirement of collision freedom between these 
two traffic agents to safety requirements of a single agent Ci\\ Pi. A follow- 
up paper will show, how by a combination of first-order model checking and 
Lyapunov’s approach of establishing stability for the individual modes such local 
verification tasks can be fully automated. 

3 A Proof Rule for Cooperating Traffic Agents 

This section develops a generic proof-rule to establish collision freedom between 
cooperating traffic agents. In doing so, we contribute to the verification of this 
class of properties in two ways. First, by extracting a generic pattern, we iden- 
tify the key ingredients involved in such classes of cooperation protocols. We are 
guided in this process by the in-depth knowledge of a spectrum of applications, 
notably from the train system and the avionics domain, and will use examples of 
each of these domains, which demonstrate, how the generic approach we develop 
can be specialized to both concrete protocol instances, though they differ in a 
significant number of design decisions. Jointly, the two example show, that we 
can cover with one generic scheme the design space ranging from completely 
symmetric solutions without fail-safe states, to asymmetric solutions involving 
heterogeneous traffic agents with fail safe states. Secondly, the proof rule demon- 
strates, how the verification problem for collision freedom, which involves a hy- 
brid system composed of two traffic agents - each a pair (C, || Pj) of the agent’s 
controller and its plant-model ~ can be reduced to simpler verification tasks, of 
the following classes: 
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(A) Off-line analysis of the dynamics of the plant assuming worst-cases dynamics 

(B) Mode invariants for 0i || O2 

(C) Real-time properties for Cj 

(D) Local safety properties, i.e. hybrid verification tasks for Cj || Pj 

Type (A) verification tasks capture, how we can capitalize on rigorous design 
principles for safety-critical systems, where a high degree of robustness must 
be guaranteed in cooperation procedures for collision avoidance. This entails, 
that potentials for collision must be analysed assuming only a minimum of well- 
behavedness about the other agent’s behavior, as expressed in invariance proper- 
ties guaranteed by the controller (these will lead to proof obligations of type (D). 
As a concrete example, when analyzing a two-aircraft system, given their cur- 
rent position and speed, we will bound changes in speed, height and direction 
when analyzing their worst case behavior in detecting potentials for collision. 
These invariances reflect typical requirements for flight phases - the aircraft 
must stay within safety margins of its current flight corridor, and maintain a 
separation with aircrafts traveling in the same flight corridor ahead and behind 
the considered aircraft. Type (A) verification tasks are simple, because they do 
not involve reasoning about hybrid systems. They consider the evolvement of all 
possible trajectories from a subregion of Pi || P2 and asks about reachability of 
forbidden plant regions. In this analysis trajectories are evolving according to 
the differential equations of Pi || P2,^ with input changes restricted by constants 
(such as maximal allowed setting of actuators) or invariances guaranteed by the 
controller (such as “velocity is within the interval [wmim invariances 
bounding disturbances specified as operating conditions (such as “the maximal 
slope for a track for high-speed trains is 5 °/oo”)> which must be stated as plant 
invariances in order to enter the analysis. 

Type (B) verification tasks ensure, that both agents take decisions which co- 
operate in avoiding potential collision situations. To this end, we assume that 
each controller has a designated set of modes called correcting modes, which 
define the agents capabilities for performing collision avoidance maneuvers. Ex- 
amples of maneuvers are the resolution advisories issued by TCAS, such as 

“climb” , “descend” , Clearly, the combined system of two aircrafts will only 

avoid collisions, it the advisories of the two controllers match. E.g. in most sit- 
uations, asking both aircrafts to climb, might actually increase the likelihood of 
a collision. It is the task of the designer of the cooperation protocol, to desig- 
nate matching pairs of modes, and to characterize the plant states of Pi || P2 
under which invoking a matching pair of maneuvers is guaranteed to resolve a 



^ Recall that plant-models are assumed to only have a single discrete state. Note that 
we can still model so-called switched dynamical systems, where the dynamics of the 
system depends on the setting of switch variables, typically occurring as input to 
the plant-model. Worst-case analysis is then performed for all valuations of switch 
variables conforming to invariant properties. Here it will sufficient to work with 
over-approximations (such as the flow pipe approximation technique developed in 

[ 5 ]). 
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potential collision situation. Demonstrating, that two matching maneuvers avoid 
collision when the maneuvers are invoked in a state meeting the characterizing 
predicate is a type (A) verification task. Demonstrating, that only matching cor- 
recting modes are selected by the protocol leads to simple invariance properties 
for Cl II C 2 . 

Finally, type (C) verification conditions stem from the need to enforce timeli- 
ness properties for correcting maneuvers. At protocol design time, upper bounds 
on the time interval between detecting a potentially hazardous plant state and 
the actual invocation of correcting maneuvers must be determined. Establish- 
ing these timeliness properties allows to place further bounds on the state-space 
exploration in type (A) verification tasks. 

We start the formal development of our proof rule by formalizing our notion 
of collision freedom as maintaining disjointness of the safety envelopes associated 
with each traffic agent. A safety envelope of an agent is a vicinity of its position 
which must not overlap the other agent’s safety envelope for otherwise a collision 
might not be safely excluded. This vicinity may depend on the agent’s state. For 
instance, a railroad crossing might be passed by trains if the barriers are closed 
and the crossing is considered safe. Then, its safety envelope is empty, otherwise 
it covers the width of the crossing. The safety envelope of the train encloses all 
of the train. 

In our second example, that of the TCAS system, we have a more symmetrical 
situation. Both aircrafts have a nonempty safety envelope when in flight, which 
must be sufficient to exclude any dangerous interferences (direct collisions or 
turbulances due to near passage) between planes. 

In the formal definition, safety envelopes are convex subspaces of sur- 
rounding the current position, whose extent can be both dependent on the mode 
as well as the current valuation of other plant variables, including in particular 
the current velocity. 

Definition 5. The safety envelope of an agent is a function 

SE : M X ^ 'P(R3), 

which in our applications is a convex subset o/K^ including the current position, 
i.e. if SE{m, a) = S then {a{x),a{y),a{z)) € S. Given a run tt, and a point in 
time t, the current safety envelope is given by SE(7r(f)). 

Collision freedom of traffic agents is satisfied, if in all trajectories of the com- 
posed traffic system (Ci || Pi) ||(C '2 || P 2 ) the safety envelopes associated with 
(Cl II Pi) and (C2 II P2) have an empty intersection (assuming that trajectories 
start in plant states providing “sufficient” distance between the agents, a predi- 
cate to be made precise below). 

Definition 6. Two runs tti and tt 2 are collision free if 

y t G Time : SEi(7Ti(t)) n SE2(7T2(t)) = 0. 

Two sets of runs are collision free if each pair of runs of the respective sets 
are collision free. 
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We will now introduce a set of verification conditions, which jointly allow to 
infer collision freedom, and start by outlining the “essence” of collision avoidance 
protocols, as depicted in the phase-transition diagram of Fig. 1 




Fig. 1. Phase transition diagram for proof rule 



Fig. 1 distinguishes the following phases of such protocols. Phase FAR sub- 
sumes all controller modes, which are not pertinent to collision avoidance. The 
protocol may only be in phase FAR if it is known to the controller, that the 
two agents are “far apart” - the agents’ capabilities for executing maneuvers are 
such, that maintaining collision freedom can be guaranteed by not yet invoking 
correcting actions. Determining conditions for entering and leaving phase FAR is 
thus safety critical. The NEGOTIATION phase is initiated, as soon as the two 
agent system might evolve into a potentially hazardous situation. The derivation 
of the predicate ip^ guarding transition (1) is non-trivial and discussed below. 
Within the negotiation phase, the two agents determine the set of maneuvers 
to be performed. The CORRECTING phase is entered via transition (2), when 
matching correcting modes have been identified and no abnormal conditions - 
discussed below - have occurred. During the correcting phase, control laws asso- 
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dated with the correcting modes will cause the distance between traffic agents 
to increase, eventually allowing to (re-)enter the FAR-phase via transition (3). 

The cycle of transitions numbered (1) to (3) described above characterizes 
successful collision avoidance maneuvers. Other phases and transitions shown 
in Fig. 1 increase the robustness of the protocol, by providing recovery actions 
in case of protocol failures in the negotiation phase (e.g. because of disturbed 
communication channels). A key concept here is that of fail-safe states: we say 
that a traffic agent offers a fail-safe state, if there is a stable state of Cj || Pj, 
i.e. a valuation of the plant variables and actuators, such that their derivative is 
zero, and in particular the traffic agent maintains its current position, such as 
e.g. for train-system applications. For such traffic agents, any failure encountered 
during the negotiation or correcting phase will lead to the activation of recovery 
modes, whose control law will be guaranteed to drive the agent into a fail-safe 
state, as long as it is entered within a predicate characterizing its application 
condition. For simplicity, we assume only a single designated recovery mode for 
such traffic agents. Correcting collision avoidance even in case of failures can 
only be guaranteed, if both agents offer fail-safe states, and the recovery modes 
driving the system to a fail-safe state are entered while the plant is (still) in a 
state meeting the application condition for both recovery modes. Transitions (4) 
and (5) are guarded by conditions catering for 

— an inconsistent selection of correcting modes, 

— a timely invocation of recovery actions so as to allow the system to reach 
the fail-safe state. 

As mentioned above, we assume the existence of an upper bound on the time 
to conclude the negotiation phase, and exploit this in analyzing, that correcting 
maneuvers are initiated in time for the maneuver to be performed successfully. 
To guarantee success of recovery actions, we similarly exploit the fact, that 
either the negotiation phase is concluded within the above bound, or a failure 
is detected and recovery mechanisms are initiated. Transition (5) provides an 
additional safeguard, in that the transition to the recovery mode will be taken 
as soon as its application condition applies. The activation of such recovery 
mechanisms should only be performed, if in addition the duration allowed for 
a successful conclusion of the negotiation phase has expired. Once the recovery 
mode is entered, the system will then eventually be driven to a fail-safe state via 
transition (6), causing it to remain in phase SAFE. 

For systems not offering fail-safe states, no formal analysis can be performed 
as to the effects of initiating a recovery strategy. Recovery modes for such sys- 
tems reflect the “never-give-up” design strategy for safety-critical systems, where 
“best guesses” as to the possible state of the other agent are made in the deter- 
mination of control-laws associated with such recovery modes. 

The phase-transition diagram defines a set of type (C) verification tasks ap- 
pearing as premises of our proof rule for establishing collision freedom. To in- 
stantiate the proof rule for a concrete conflict-resolution protocol, the phases 
discussed above must be defined as (derived) observables of the concrete pro- 
tocol. Often, phases can be characterized by being in a set of modes of the 
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concrete protocol. In general, we assume that phases are definable by first-order 
quantifier-free formula in terms of the variables and mode of the concrete system. 
We denote by <Pobs the set of equivalences defining phases and transition guards 
in terms of the entities of the concrete protocol. It is then straightforward to 
generate verification conditions enforcing compliance of the concrete protocol to 
the phase-transition system of Fig. 1, such as by using the subclass of so called 
“implementables” of the Duration Calculus (c.f. [15]), or some variant of real- 
time temporal logic. Such verification conditions take the general form “when in 
phase p then remain in phase p unless trigger condition occurs”, and “when in 
phase p then switch to phase p' if trigger condition is met”.® We denote the set 
of temporal logic formula jointly characterizing the phase-transition diagram of 
Fig. 1 assuming by ^ph ase- 

This leads to the first set of verification conditions for establishing collision 
freedom. Here and in the remainder of this section we assume a fixed system 
(Cl II Pi) II (C 2 II P 2 ) as given. 

(VC 1) Controllers observe phase-transition diagram 

Cl ^ phase (for i = 1,2) 

Prior to deriving trigger conditions for phase-transitions, let us first elaborate 
on three verification conditions to be established by what we refer to as “off-line 
analysis” . These verification conditions serve to establish at design time, that the 
invocation of matching maneuvers will guarantee collision freedom, as long as 
these are initiated while the global plant state satisfies a predicate characterizing 
the application condition of the pair of maneuvers. A similar off-line analysis 
must be carried out for recovery mechanism, where it must be verified, that any 
plant state meeting the application condition for such recovery states will drive 
both agents into their fail-safe state prior to reaching a collision situation. 

As discussed in Section 2, we assume as given a subset of correcting modes 
CMj of the Modes Mj of Cj. If Cj has fail-safe states, we denote by rrirec 2 fss,Cj 
the unique mode of Cj defining the control strategy for reaching fail-safe states. 

We assume a binary relation MATCH C CMi x CM 2 to be given, which 
captures the designer’s understanding, of which maneuvers are compatible and 
hence expected to resolve potential collision situations. To this end, she will also 
determine application conditions where (mi, m 2 ) G MATCH, under 

which these maneuvers are expected to be successful. Typically, these applica- 
tion conditions will involve the relative position of the traffic agents, as well as 
their velocity. Maneuvers are typically executed under assumptions on some of 
the system variables (e.g. bounding speed or lateral movement), which must be 
established separately. Similarly, let ^rec 2 fss denote the application condition for 
recovery to fail-safe states (see the following sections for examples). 



® We assume in this paper that the successor phase is uniquely determined by the 
trigger condition. Time-bounds on taking the transition when the trigger is enabled 
are discussed below. 
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The first verification condition requires a proof, that indeed matching maneu- 
vers avoid collision. It states that all trajectories obeying the set of differential 
equations governing the maneuvers and the plants will be free of collisions, as 
long as they are initiated in a state satisfying the application conditions of match- 
ing modes. The runs to be considered are assumed to meet the plant invariants 
on boundary conditions for the plants’ variables. Moreover, any local invariances 
associated with the correcting modes may be assumed during off-line analysis - 
separate verification conditions cater for these. 

(VC 2) Adequacy of matching modes 
V (mi, m 2 ) G MATCH : 

{RhArn,)\\R^P^0)\\{RK0\\{Rh(rn2))) 

^ □(0(mi) A 0 ( 1712 ) A 0{Pi) A 0{P2) A 
^ □(collision-free) 

A key point to note is, that the above verification condition does not involve 
state-based reasoning. By abuse of notation, we have replaced hybrid automata 
by differential equations in the parallel composition above. To establish the ver- 
ification condition, we must analyze the possible evolution of trajectories of the 
plant variables in subspaces characterized by the application condition. We can 
do so by over-approximation, using boundary conditions on plant variables (such 
as maximal speed, maximal acceleration, maximal disturbance) and actuators 
(as determined by the control laws associated with the correcting modes), and 
invariance conditions associated with correcting modes. See the next section for 
a concrete example, demonstrating in particular the ease in establishing such 
verification conditions. For more involved maneuvers, we can resort to classical 
methods from control-theory such as using Lyapunov functions (c.f. [9]) for es- 
tablishing collision freedom, since no state-based behaviour must be analyzed. A 
follow-up paper will solve the constraint system induced by (VC 2) generically, 
establishing constraints on the involved design parameters under which (VC 2) 
is guaranteed to hold. 

A similar verification condition must be established for recovery modes driv- 
ing the system to fail-safe states. It requires each traffic agent to reach a fail-safe 
state without colliding with the other agent, as long as the recovery maneuver 
is initiated in a plant state meeting its applicability condition. 

(VC 3) Adequacy of recovery maneuvers 

(-^Ci(^rec2fss,l) II Rpj^O) IK-RP 2 O II -Rc2(”^rec2fss,2)) 

1= □(0(rni"ec2fss,l) A 0(7/irec2fss,2) A 0(P±) A 0(P2) A ^rec2fss) 

=> Ofail-safe A □ collision- free 

So far we have only discussed the adequacy of the maneuvers for avoiding 
collision avoidance. This must be complemented by a proof of completeness of 
the proposed methods. More specifically, for any trajectory of the unconstrained 
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plants (respecting only global invariances on maximal disturbances, maximal 
rate of acceleration, etc) leading to a collision situation, there must be at least be 
one pair of matching maneuvers, whose application condition is reached during 
the trajectory. 

(VC 4) Completeness of maneuvers 

G [Pi I! P 2 ] : 7t h 0{Pi) A e{P2) ^ 

(V t : 'K{t)\= collision A 7 t[ 0, t) |= collision-free 

3 t' < t 3(m, m‘) G MATCH : Tr(t') ^ ) 

We will now derive a sufficient condition for the predicate guarding the 
transition to the negotiation phase. This must ensure, that in any potentially 
hazardous situation, the negotiation phase is allowed in time to ensure, that 
correcting maneuvers can still be executed successfully. To derive this condition, 
we perform the following simple Gedankenexperiment. Assume, that the negoti- 
ation phase can be performed in zero time. Then, by completeness of maneuvers, 
it would be sufficient to trigger the transition into the negotiation phase, if at 
least one activation condition of the set of possible maneuvers is met. Indeed, by 
completeness, any potentially hazardous “legal” trajectory would have to pass at 
least one of the activation conditions of the set of maneuvers, hence by selecting 
one of these, the maneuver will ensure, that the potentially hazardous situation 
is resolved (by the adequacy of matching correcting modes) . 

To complete the Gedankenexperiment, we now drop the assumption, that ne- 
gotiation is performed in zero time. Instead, we assume that at protocol design 
time, a time window is determined, in which the negotiation phase will be 
left, either successfully, by entering phase CORRECTING, or otherwise by in- 
voking a recovery mode. To determine the trigger condition we must derive 
the set of states which can evolve during this time window A ^ into a potentially 
hazardous situation, i.e. into a state meeting at least one of the activation con- 
ditions of matching maneuvers. When performing this pre-image computation, 
we must take into account the dynamics of both traffic agents. In this paper, 
we assume a cooperative approach: the pre-image computation is performed, as- 
suming that the speed of the traffic agent is not increased while performing the 
negotiation phase - an assumption, which must then be established separately 
as verification condition. 

Let pre = prep^ y P 2 (A, [u 2 ,i, U 2 ,u], ^) be a predicate which over- 

approximates the set of plant states which in A time units can evolve into a state 
satisfying assuming that the speed v of agent i is bound by [vp;, (a vector 
of bounds for all three dimensions, if applicable), and restricted by 0{Pi). (VC 5) 
below expresses the restriction on the condition triggering the transition to 

phase NEGOTIATING, given the time bound for the NEGOTIATION to 

complete. 

(VC 5) Negotiation is initiated in time 

h ^ prep^ II p^{An, [vi^i, Vi^u], [V2,h V 

( mi, m2 )G MATCH 
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That An is met by the agents’ negotiation is to be verified separately. We 
assume that the necessary communication can be performed by the controllers 
on their own. 

(VC 6) Negotiation completes in time 

Cl II C 2 h □(NEGOTIATING(Ci) V NEGOTIATING(C2) 

^ 0<zi„(-NEGOTIATING(Ci) A ^NEGOTIATING(C2))) 

To cover the assumptions made in preconditions, we require the control laws 
active during the negotiation phase to maintain the speed of traffic agents within 
the bounds used in (VG 5) in pre-image computation. 

(VC 7) Speed stays bounded during negotiation 

Q II A h □(NEGOTIATING(C,) ^ v, € (for z = 1,2) 

For traffic systems allowing recovery to fail-safe states, we would like to ensure 
additionally, that the negotiation is initiated in system states allowing to invoke 
recovery actions if negotiation fails. 

(VC 8) Recovery actions will be possible 

\=<Pn ^ prep^ II p^{An, [wi,P Wi,«], [v2,U W2.«], f^rec2fss) 

Jointly, (VC 5), (VC 6) and (VC 7) guarantee, that the activation conditions 
of maneuvers remain true during negotiation, hence are still valid when actually 
invoking the maneuvers, and (VC 7) in conjunction with (VC 6) and (VC 8) 
guarantees, that the activation condition for recovery to fail-safe states is met, 
if the negotiation phase fails. 

That the negotiation results in matching modes being selected is stated in 
the following condition. 

(VC 9) Only matching modes with satisfied activation condition are selected 

Cl II C 2 h °(T (CORRECTlNG(Ci) A C0RRECT1NG(C2)) 

(Mode(Ci),Mode(C 2 )) G MATCH A ^(Mode(Ci),Mode(C 2 ))) 

We must finally ensure, that a selected maneuver is not abandoned until the 
hazardous situation has been resolved, i.e., until phase FAR can be reentered. 
Hence, while in mode CORRECTING, the maneuver may not be changed. 

(VC 10) Correcting modes are not changed 

Cl II C 2 h V (mi, m 2 ) G MATCH : 

□ ( f\ CORRECTlNG(a) AMode(a) = m, 

i^l,2 

^ !\ (Mode(a) = m* while C0RRECT1NG(C,))) 

z^l,2 
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The condition guarding the transition to phase FAR is easily derived: by 
completeness of the set of maneuvers, the plant state is no longer potentially 
hazardous, if all activation conditions of maneuvers are false. In this case, the 
controllers are permitted to leave the correcting mode. 

(VC 11) Termination of Maneuver 
1 = ^ 

(mi.maleMATCH 

Jointly, these verification conditions are sufficient to establish collision free- 
dom. A later version of this paper will prove this formally, by performing the 
required off-line analysis and pre-image computation symbolically on parameter- 
ized models. In the following, we give two examples of proofs of collision freedom 
and discuss how they can be rephrased in terms of our proof rule. 



4 Decomposition in the Verification of Safety of the 
TCAS System 

4.1 A Short Description of the TCAS System 

The Traffic Alert and Collision Avoidance System (TCAS) serves to detect and 
avoid the danger of aircraft collisions. It is realized by electronic units on board 
of the aircraft. Its task is to detect potential threats, to alert the pilot and to 
give advice in maneuvers which resolve the conflicts. To achieve this, the system 
gathers information from nearby aircraft to predict the vertical separation at the 
point of closest horizontal approach. If the vertical separation is deemed insuffi- 
cient, it issues “Resolution Advisories” (RAs) to the pilot (“climb”, “descend”, 
. . . ) which, assuming unchanged horizontal course, shall avoid that the aircraft 
come dangerously close. The TCAS units of different aircraft communicate, to 
alert the other of its classification as a threat, to ensure consistency of RAs, and 
to avoid unnecessary alarms by taking intended course changes into account. 
Each TCAS system resorts to deciding on its own if communication cannot be 
established. Fig. 2 from [11] gives an overview of the components involved in 
conflict avoidance in the case of two aircraft. 

There have been several versions of the system. We will discuss the TCAS II- 
7. This version is in widespread use, and has undergone quite some analysis, both 
internally during its development and externally in e.g. [1]. The precise analysis 
from [11] comes closest to our approach, and we will point out similarities and 
differences, to highlight to which extent the formulated goal of establishing safety 
has been proven to be achieved by the TCAS system. 

4.2 The Analysis of TCAS by Livadas, Lygeros and Lynch 

The general approach of [11] is to use hybrid automata to model all components 
involved in conflict avoidance for a two-aircraft instance, and to analyse the runs 
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Advisories Advisories 



Fig. 2. TCAS-System for two aircraft 



of the combined automata to check for the absence of collisions. The real system 
would then have to shown to be a refinement of the respective components (or 
have to be assumed to act as it were a refinement - the model includes compo- 
nents for pilots, which would hardly be provable refinements of an automaton). 
Though the automaton format differs (hybrid I/O automata with superdense 
time are used), this is very much in line with our approach. 

Several assumptions are stated under which the analysis is performed. Some 
of them serve to reduce the computational complexity of trajectory analysis, 
which may limit the practical relevance but is conceptually reasonable. Some 
are even indispensable, as the one restricting pilot behavior to not oppose traffic 
advisories. Others limit the relevance of the derived safety result if compared to 
our stated goal. Our discussion will center around these latter issues. 

Disregarding simplifying assumptions, the safety theorem of [11] can be stated 
as follows: 

All assumption-compliant runs where a conflict is detected will either 
evolve to retraction of the conflict declaration before passage, or to a 
passage where sufficient vertical separation is kept at the point of closest 
approach. 

This can be rephrased as saying that the proof establishes that the interplay 
between discrete and continuous components will ensure that TCAS’ operational 
goals are met. An “operational” goal is formulated via the system’s own defini- 
tions: 
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~ A “conflict” is deflned as the system’s conflict-detection component deflnes 
it. 

~ “Undeclaration” of a conflict is similarly taken from the respective system 
criterion. 

— Collision-freedom of two trajectories is given if passages have sufficient ver- 
tical separation. 

This theorem tells a lot about the effects of TCAS - the vertical separation 
will be achieved as required in the system specification. However, it does not 
imply that two aircraft guided by TCAS will not collide. The latter is an exten- 
sional property, the former is intensional and presupposes that the operational 
specification is consistent (which is, considering the rather successful history of 
guaranteeing safety in air traffic, not unreasonable). But our verification goal 
would be more ambitious. So let us have a look at the verification conditions of 
our rule which have been established in [11], and those which would have to be 
added. 

4.3 Items for Completing the Analysis 

The extensional goal is formulated in terms of safety envelopes. Such notions do 
exist in air traffic regulations - there is for instance a safety distance between 
landing aircraft which depends on the weight class of the leading aircraft. Similar 
separation requirements can be derived for mid-air traffic. So we may assume 
adequate definitions of safety envelopes as given. 

Our approach presupposes a compliance of the resolution procedure to the 
state diagram Fig. 1. In the case of TCAS, there are no fail-safe states, which 
reduces the picture to the three states FAR, NEGOTIATING and CORRECT- 
ING. On the other hand, as TCAS follows the “never give up” strategy, there 
are further situations not taken care of in the general picture. We will have to 
extend our approach to cater for these. In the meantime, we resort to excluding 
further behavior from our analysis by adequate assumptions. Then, one may 
indeed view TCAS II-7 as adhering to the three-state cycle, if attention is re- 
stricted to the two-aircraft case. Adherence to the behavior pattern is implicitly 
shown in [11], we may conclude that (VC 1) does not pose a problem. 

As there are no fail-safe states, the verification conditions (VC 3) and (VC 8) 
do not apply here. We will go through the list of remaining verification conditions 
in the following. 

A central part of the adequacy of matching modes (VC 2) is indeed estab- 
lished by the essence of the proof from [11]: Trajectories resulting from selected 
correcting strategies will result in sufficient separation. To complete the proof of 
(VC 2), we have to add that the intensional (TCAS-internal) criterion of “verti- 
cal separation at closest approach” implies disjointness of safety envelopes. This 
will (likely) be a consequence of the bounds on climb and descend speeds of 
aircraft following TCAS resolution advisories. Of course, also a precise defini- 
tion of the conditions matching modes will be required to formally 

complete the proof. 
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The completeness of maneuvers, (VC 4), is also addressed partly: After a 
conflict has been detected, there will be a pair of maneuvers selected. To be 
added is the important argument that each conflict is detected, and detected 
in time for some maneuver to be successful. This is again the (missing) part 
distinguishing intensional and extensional arguments. 

The conditions regarding timing (VC 5), and (VC 6) have been left out of 
consideration by adding appropriate assumptions. The speed bound (VC 7) is 
rendered trivial by assumption. Adding proofs (and weakened assumptions) for 
these three verification conditions would be rather easy. 

The selection of matching modes with satisfied verification conditions (VC 9) 
is addressed implicitly by the proof, since for all cases of selections it is shown 
that the corrections will be successful. Our proof rule requires a separation of 
the proof via the introduction of MATCH and ^ case split according 

to the matching mode pair is actually performed in [11], and can be extended 
to the additional proof obligations. 

Adherence to a selection of correction modes (VC 10) is a condition simpli- 
fying our proof rule and restricting the solution space. TCAS II-7 matches this 
restriction, if the definition of correction is made adequately, and “never give 
up” is left out of consideration. The reversal of correcting actions in one aircraft 
- one of the new features in the version II-7 - seems to violate this requirement. 
But it fits into the picture as it reverses a correcting maneuver which has started 
before the end of negotiations. The reversal caters (among others) for the not 
unlikely situation that one aircraft pilot ignores resolution advisories. 

Termination of maneuvers (VC 11) is of course also not addressed exten- 
sionally in [11]. We think that it will follow easily from the definition of the 
application conditions 

5 Decomposition in the Verification of Safety of a 
Railroad Crossing 

Railroad crossings are often taken as case studies for real-time systems [3,7]. 
Here we consider a railroad crossing as a hybrid system taking the continuous 
dynamics of train and gate into account. Our formal model extends that in [14] by 
some aspects of the radio controlled railroad crossing, a case study of the priority 
research program “Integration of specification techniques with applications in 
engineering”® of the German Research Council (DFG) [8]. 

We start from domains Position = K>o with typical element p for the position 
of the train on the track and Speed = M>o with typical element v for the speed 
of the train. Let Vmax denotes the maximal speed of the train. As part of the 
track atlas we And the positions of all crossings along the track. In particular, 
the function 

next : Position Position 



http : / /tf s . cs.tu-berlin.de/projekte/ indspec/SPP/index .html 
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yields for each position of the train the start position of the next crossing ahead 
such that Vp S Position : p < next{p) holds. Further on, 

inCr : Position B 

is a predicate describing all positions in the crossing and 
afterCr : Position — > B 

is a predicate describing the positions in a section immediately after the crossing. 
For simplicity we shall not be explicit about the extension of the train and the 
crossing. We use inCr to describe all positions where the train (or its safety 
envelope) overlaps with the crossing. 

There is a section near the crossing in which the train has to request per- 
mission from the gate to enter the next crossing. The extension of this section 
depends of the train’s speed. The predicate 

nearCr : Speed — > (Position B) 

describes for a given speed all positions and that are in such a section. The 
positions satisfying these predicates are illustrated in Fig. 3. The predicate 

farCr : Speed (Position B) 

describes for a given speed v all positions that are far away from the next cross- 
ing, i.e. the complement of all positions satisfying nearCr(v) or inCr or afterCr. 
Note that we expect the following implications to hold: 

V wi < U 2 G Speed : (nearCr(vi) nearCr(v 2 )) A (farCr(v 2 ) => farCr(vi)) 

We assume that subsequent crossings on the track are far apart so that even 
for the maximal speed Vmax of the train there is a nonempty section farCr(vmax) 
between each section afterCr and the section inCr of the next crossing. We model 
the gate by its angle a ranging from 0 to 90 degrees. 




nearCr(v) 



\ 




next(p) \ 

inCr 



Fig. 3. Parameters of the railroad crossing 



The railroad crossing will now be modelled by four components: a train plant 
and controller interacting with a gate plant and controller. Fig. 4 shows how 
these plants are represented by continuous variables pos(ition), speed and a, 
and which variables the four components share for communication with each 
other. For simplicity we shall ignore the communication times in the subsequent 
analysis. 
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Fig. 4. Communication in the train gate system 



Train Plant 

We assume that the train has knowledge of its position on the track and controls 
its speed depending on requests from the train controller. It will react to speed 
control commands from the train controller. Thus we consider the variables 
below. We do not distinguish between the (syntactic) variables of the automaton 
and the corresponding trajectories in runs. So we take for the type of a variable 
the type of its time-dependent trajectory, and we permit variables with discrete 
ranges without explicitly coding them in reals. 



Variables: 


input 


sc : Time - 


-f {Normal^ Keep, Brake} 


(speed control) 


output 


pos : Time - 


-> Position 


(position of the train) 




speed : Time - 


-> Speed 


(speed of the train) 



Dynamics. Let —a^eg be the deceleration of the train when braking (in regu- 
lar operational mode, not in emergency mode which is not modeled). Thus we 
assume that the following invariants hold: 



pos* = speed 
— ttreg < Speed' 
speed < Vmax 



100 W. Damm, H. Hungar, and E.-R. Olderog 



Here we are interested only in the change of speed during braking: 

{ 0 if sc = Keep V (sc = Brake A speed = 0) 

— areg if SC = Brake A speed > 0 
if sc = Normal 

With these characteristics we can calculate for which speeds v and positions 
p the predicate nearCr{v){p) should hold taking the maximal closing time Smax 
of the gate into account: 

nearCr{v){p) -t= {next{p) - u^/2 • areg ~ s-max ■ v) < p 

Here c^/2 • areg is the maximal distance it takes for the train with an initial 
speed of v to stop, and Smax • v is the maximal distance the train can travel while 
the gate is closing. Remember that we do not take the time for communication 
into account here. We assume that initially the train is far away from the next 
crossing, i.e. the predicate farCr (speed) (pos) holds for a while. This, and the 
definition of nearCr(v)(p) is needed for establishing (VC 4). 



Train Controller 

The train controller monitors the position and speed of the train, sends requests 
to enter the next crossing, and waits for an OK signalling permission by the 
crossing to enter. If this OK signal does not occur within some time bound 
measured by a clock x, the train controller will request the train to enforce 
braking in order to stop before entering the crossing. Thus the train controller 
has the following time dependent variables. 



Variables: 


input 


pos : Time 


^ Position 


(position of the train) 




speed : Time 


Speed 


(speed of the train) 




OK : Time 




(permission to enter crossing) 


local 


X : Time 


^ Time 


(clock) 


output 


Req : Time 


^B 


(request to enter crossing) 




sc : Time 


^ {Normal, 

Keep, Brake} 


(speed control) 


Modes: 


Far, Appr, 


Safe Appr, Fail Safe 





Dynamics. The dynamics of the train controller is described by the hybrid au- 
tomaton in Fig. 5. Initially, the controller is in the mode Far. When for the 
current values of pos and speed the predicate near (speed) (pos) becomes true. 
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the controller switches to the mode Appr setting Req to true and starting the 
clock X. When things proceed as expected the crossing should respond with an 
OK signal within £max time, the maximal time the gate needs to close. On oc- 
currence of OK the controller switches to the mode SafeAppr indicating that 
the train can safely approach the crossing. However, if the OK signal does not 
arrive within £max time, the controller enters the mode FailSafe where the train 
is forced to brake until it stops. Only if later an OK signal arrives it may resume 
its safe approach to the crossing. 




Fig. 5. Train controller 



The controller states correspond nicely to the phases from Fig. 1: Far is 
FAR, Appr is NEGOTIATING, FailSafe is REGOVERY, and SafeAppr is 
GORREGTING. The only action the train does in correcting is keeping the Req 
signal up.^ 



Gate Plant 

The gate controls its angle a depending on the direction requested by the variable 
Dir of the gate controller. If Dir is Up the gate should open, and if it is Down the 
gate should close. The gate outputs whether it is completely open by a signal 
Op or completely closed by a signal Cl. We take into account that the gate may 
fail to open or close when requested. This it is modelled by the following time 
dependent variables. 



^ Thus, one might also view the mode Appr as already CORRECTING. 
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Variables: 



input 


Dir : Time - 


{ Up, Down} 


(direction of the gate) 




Fail : Time - 


-4 B 


(gate failure) 


local 


a : Time - 


[0, 90] 


(angle of the gate) 


output 


Op : Time - 


B 


(gate is open) 




Cl : Time - 


B 


(gate is closed) 



Dynamics. We assume that initially the gate is open. i.e. a(0) = 90, that c is 
the speed with which the gate can change its angle a, and that the gate plant 
is characterised by the following differential equation: 

{ c if Dir = Up A a < 90 A ^Fail 

— c if Dir = Down A a > 0 A ~^Fail 

0 otherwise 

Thus when there is no gate failure the maximal closing time Smax of the gate 
(plus one extra second) is calculated as follows: 

^max ~ 90/c + 1 

The outputs Op and Cl are coupled with the angle of the gate by the following 
invariants: 

Op AA a = 90 and Cl AA a = 0 

Gate Controller 

The gate controller reacts to the presence or absence of requests by the train 
(controller) to enter the crossing by issuing CoUp and CoDown signals to the 
gate plant. Depending on the messages Op and Cl of the gate plant it can 
signal an OK to the train controller as a permission to enter the crossing. This 
motivates the following time dependent variables. 



Variables: 


input 


Op : Time 


B 


(gate open) 




Cl : Time 


B 


(gate closed) 




Req : Time 


B 


(request to enter crossing) 


output 


Dir : Time 


{ Up, Down} 


(direction of the gate) 




OK : Time 


B 


(permission to enter crossing) 


Modes: 


CrUnsafe, 


CrSafe, CloseGate, OpenGate 
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Dynamics. The dynamics of the gate controller is described by the automaton 
in Fig. 6. Initially, the controller is in the mode CrUnsafe where it does not 
grant any permission to enter the crossing. When it senses a request by the train 
to enter it orders the gate to go down and switches to the mode CloseGate. 
It stays there until the gate signals that it it completely closed. Only then the 
controller gives permission to the train to enter the crossing by issuing an OK 
signal and switches to the mode CrSafe. It stays there until the request to enter 
the crossing is withdrawn. Then the controller switches to the mode OpenGate, 
withdraws the permission to enter the crossing and orders the gate to go up. 
When the gate is completely open, the controller switches back to its initial 
mode. 




Fig. 6. Gate controller 



The mode GrUnsafe belongs to the gate’s phase FAR, GloseGate and 
GrSafe form the phase CORRECTING, and OpenGate is again FAR. The 
phase NEGOTIATING has no corresponding mode in this model: The gate does 
not negotiate, and one may view the transition from CrUnsafe to CloseGate 
as passing NEGOTIATING in an instant. 



Correctness Proof 



Desired Safety Property. We wish to show that whenever the train is in the 
critical section the gate is closed. This might be formulated in terms of safety 
envelopes as follows. For SE TVam(pos) we choose an extension around the current 
position pos which encompasses the extension of the train, independent of mode 
and speed. The crossing’s safety envelope is 



SEcr{m) 



0 if m = CrSafe 
Q otherwise 
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for some adequate set of positions Q. This choice of 0 as the extension of the 
safety envelope in mode CrSafe permits the train to pass the crossing when the 
bars are closed without safety violation. We assume that inCr{pos) includes all 
train positions which could, if the crossing is not safe, violate safety, i.e. 

SErrainipos) H Q ^ 0 ^ inCr{pos). 

To perform the proof, we use the State Transition Calculus [18], an exten- 
sion of the Duration Calculus [19, 15] to deal with instantaneous transitions. 
The Duration Calculus itself is a temporal logic and calculus for expressing and 
proving real-time interval properties of trajectories or observables of the form 
obs : Time Data. As a consequence of our assumption above, the desired 
safety property can then be expressed as follows: 

0{\inCr{pos)~\ \Gl~\) 

This Duration Calculus formula states that for every time intervals whenever 
the state assertion inCr{pos) about the train holds throughout this interval then 
also the state assertion Cl holds throughout the same interval. 

This property is established in a complete, self-contained proof. This proof 
is presented below, with added comments on which parts correspond to the 
verification conditions of our rule and the argument of the rule itself. 

Notation. Duration formulas are evaluated in time intervals whereas state as- 
sertions are evaluated in time points. In the following D, Di,D 2 denote duration 
formulas, S denotes a state assertion, and t G Time. 

D\', D 2 (chop operator) holds in a given time interval 

if first Di and then D 2 holds 

OD true; D; true holds in a given time interval 
if on some subinterval D holds 

□ D -^O^D holds in a given time interval 

if for all subintervals D holds 

holds in a given time interval 
if this is a point interval (i.e. has length 0) 

t holds for a non-point interval 
in which S holds throughout 

i holds for an interval of length t 
and S holds throughout 

holds in an interval starting at 0 
if D is followed by \S~\ 

holds in a given time interval 
if always D is followed by [b”] 



n £ = 0 

[b]44>£>0A/b = 

\sy ^e=t Afs = 

D - 
D 



0 [b] <t4> -^[D; [^b]) 

-4 [b] <t4> □^(D; [^b]) 
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D — ^ \ S~\ {D A i = t) — > l"^] holds in a given time interval 

if whenever D is true for t time 
it is followed by |’5'] 

t S (start transition) holds for a point interval where S 

switches from false to true 

I S (end transition) holds for a point interval where S 

switches from true to false 

To avoid unnecessary brackets, we assume that the chop operator ; binds 
stronger than the binary Boolean connectives and the derived bi- 
nary operators — > 0 ) — A In state assertions, equations obs = d are 

abbreviated to d if it is clear to which observable obs the data value d be- 
longs. For instance, \Keep~\ abbreviates [sc = Keep~\. For Boolean observables 
obs we abbreviate obs = true to obs. For instance, \Cl~\ abbreviates \Cl = 
true~\ . 

Train Plant. The properties of the train plant are expressed in the State Tran- 
sition Calculus as follows: 

Invariants: 

□ [pos* = speed'] 

U\ speed < Vm,ax\ 

Initial state of the train on the track: 
n V \farCr{speed){posy\] true 

The assumption about the initial state is needed for (VC 4). 

Assertions about the train movements: 

\farCr{speed){posy\ — > \farCr{speed){pos) V near Cr {speed) [pos^] 
\nearCr{speed){pos)'\ — > \nearCr{speed){pos) V inCr{pos)'\ 

\inCr{pos)'\ — > \inCr{pos) V afterCr{pos)) 

\ afterCr{pos)~\ — > \afterCr{pos) \/ farCr {speed) {pos)~\ 

These assertion establish the necessary properties for reasoning about tra- 
jectories for (VC 2) and (VC 3) on the abstract level with the predicates farCr, 
nearCr, inCr and afterCr. 

The speed is stable under sc = Keep: 

V V G Speed : [ speed < v S. sc = Keep) — > [ speed < c] 

Stability of speed directly establishes (VC 7). 

Braking: 

W V G Speed : {speed <■!;]; [sc = — > {speed = 0] 

{speed = 0 A Brake) — > {speed = 0] 

V u G Speed : | nearCr{v){pos); {speed < > {nearCr{v){pos)) 

Vv G Speed : (t nearCr{v){pos); 

{speed < {{speed* = —areg) V speed = 0]'"/“’'‘«) 

— > {nearCr{v){pos)) 
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The behavior while braking is needed for the adequacy and feasibility of re- 
covery actions (VC 3) and (VC 8), while further properties of the abstract logical 
level, insofar as the interaction with the train’s movement is concerned. 

The train does not move at speed = 0: 

Vp G Position : \ speed = 0] A \pos = p~\; true □|"pos = p~\ 

Train Controller. The following characterization of the train controller of Fig. 5 
in terms of Duration Calculus formulas is not related to the decomposition proof 
rule. It only serves to lift reasoning about the automaton to the level of the 
Duration Calculus. 

Initial mode: 

n V \Far~\] true 

Mode sequencing: 

\Far~\ — > \Far V Appr~\ 

\Appr~\ — > \Appr V SafeAppr V FailSafe~\ 

\ SafeAppr~\ — > \ SafeAppr V For] 

\FailSafe~\ — > \FailSafe V SafeAppr~\ 

Stabilities: 

[For]; \ far Cr (speed) {pos)~\ [For] 

\Appr~\; il^OK) Ai < 

^max ) ^ \Appr~\ 

(SafeAppr]' after Cr(pos)] [SafeAppr] 

[Failsafe]', [^OK] ^ [FailSafe] 

Transitions upon input events: 

[For]; I near Cr (speed) (pos) — > [Appr] 

[Appr]', t OK — > [SafeAppr] 

[SafeAppr]', f afterCr(pos) — > [For] 

[ FailSafe] ; t OK — > [ SafeAppr] 

Timeout transition: 

t Appr-, [Appr] [FailSafe] 

The output variables Req and sc depend on the mode only: 

□ [For <tA -^Req] 

□ [(For V SafeAppr) AA sc = Normal] 

0[Appr AA sc = Keep] 

0[ FailSafe AA sc = Brake] 



Gate Plant. The following assumptions serve to characterize the trajectories 
resulting from the hybrid automaton in terms of the Duration Calculus formulas, 
similar to the characterization of the train plant above. 

Initial state of the gate: 

[] V [a = 90] ; true 
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Assertions on the dynamics of the gate: 

[a = 90 A Dir = fTp] — > \a = 90] 

\Dir = Up A ^Fail'] [a = 90] 

[a = 0 A Dir = Dowri] — > \a = 0] 

\Dir = Down A ^FaiV\ \a = 0] 

The output variables Op and Cl depend on the state of the gate only: 
U\Op AA a = 90] 

□ [ a a = 0] 



Gate Controller. We formalise the properties of the automaton in Fig. 6. 

Initial mode: 

n V [ CrUnsafe~\ ; true 

Mode sequencing: 

\CrUnsafe~\ — > \CrUnsafe V CloseCate^ 

\CloseCate~\ — > \CloseCate\/ CrSafe~\ 

\ CrSafe~\ — > |" CrSafe V OpenCate~\ 

\ OpenCate~\ — > |" OpenCate V CrUnsafe~\ 

Stabilities: 

\CrUnsafe~\; \^Req~\ \CrUnsafe~\ 

\ CloseGate~\] \^Cl~\ =A- \ CloseCate] 

\ CrSafe ~\ ; [ Req~\ |" CrSafe~\ 

\OpenCate~\; \^Op~\ \OpenCate~\ 

Transitions upon input events: 

\CrUnsafe~\; t Req — > \CloseCate~\ 

\ CloseCate~\; t Cl — > \CrSafe~\ 

\ CrSafe ~\ ; t ^Req — > |" OpenCate~\ 

\OpenCate\^ t Op — > \CrUnsafe'\ 

The output variables Dir and OK depend on the mode only: 
0\[CrUnsafe V OpenCate) AA Dir = Up) 

Fi\[CloseGate V CrSafe) AA Dir = Down) 

□ [ CrSafe AA OK) 



Proof of the Safety Property 

The proof of the safety property is sketched by the following timing diagrams 
showing interpretations of the time dependent variables that satisfy the above 
formulas of the State Transition Calculus. 

Fig. 7 shows the normal case where for the interval when pos takes the value 
inCr we have [ Cl) as desired. For the adequacy (VC 2) and completeness (VC 4) 
arguments, we need that the Req signal is sent in time to close the gate. As 
NEGOTIATING is rather trivial here, and MATCH consists of just one pair 
of modes, (VC 9) and (VC 10) are rather trivial. Maneuvers are terminated on 
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Cl 


^(Op V Cl) 1 Op 
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^ Fail 


U £ sL 
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OK 


^ OK 


OK 


^ OK 









Fig. 7. Sketch of proof: normal case 



reaching the noncritical Far again, which, due to the assumption on separation 
of crossings, dissatisfies the application condition of correcting maneuvers. The 
timing diagram in Fig. 7 sketches the combined behavior of controllers and 
plants, and thus subsumes (one part of) the discrete phase-transitions addressed 
in (VC 1) and the dynamic trajectories from (VC 3). 

Fig. 8 shows the failure case where upon the train’s request to enter the 
crossing the gate continues to show ~^Cl for more than Smax time and thus 
the train is prevented from entering the crossing. Here, the condition on the 
definition of nearCr{v){p) becomes essential in all its parts. It directly trans- 
lates into a condition (Prec 2 fss for the train, with resulting proof obligations 
(VC 3), (VC 7) and (VC 8), which sum up into a maximal delay in the tim- 
ing diagram from sending Req to coming to a full stop when the gate does not 
close. 

We may note that, if there were more matching modes, each would require a 
corresponding timing diagram, enforcing the use of a global diagram fixing the re- 
lations between the cases. This argumentation pattern would, by and large, have 
to follow our proof rule, only that the rule further decomposes the (somewhat 
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Fig. 8. Sketch of proof: failure case 

informal) timing diagrams into completely formalized peaces, with well-defined 
interrelations. 



6 Conclusion 

We have presented an approach to the verification of cooperating traffic agents 
and shown its applicability to two radically different examples. Future work 
will complement this paper by formally proving the soundness of the proposed 
verification rule, formally instantiating this to the examples of this paper, and 
by demonstrating how the derived verification conditions can be discharged by 
automatic verification methods. 
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Abstract. This paper introduces a general methodology for obtaining 
complete Hoare logics for object-oriented languages. The methodology 
is based on a new completeness result of a Hoare logic for a procedu- 
ral language with dynamically allocated variables. This new result in- 
volves a generalization of Gorelick’s seminal completeness result of the 
standard Hoare logic for recursive procedures with simple variables. We 
show how this completeness result can be generalized to existing Hoare 
logics for typical object-oriented concepts like method calls, sub-typing 
and inheritance, and dynamic binding, by transforming an encoding of 
these concepts into this procedural language with dynamically allocated 
variables. 



1 Introduction 

Information technology industry is still in need for more reliable techniques that 
guarantee the quality of software. This need is recognized by C.A.R. Hoare as 
a Grand Ghallenge for Gomputing Research in his proposal of the Verifying 
Gompiler [14]. 

A verifying compiler resembles a type checker in the sense that it statically 
checks properties of a program. The properties that should be checked have to be 
stated by the programmer in terms of assertions in the code. The first sketch of 
such a tool is given by Floyd [10]. In recent years, several programming languages 
(e.g., EIFFEL [16], Java [9]) have been extended to support the inclusion of 
assertions in the code. These assertions can be used for testing but they can also 
be used as a basis for a proof outline of a program. Hoare logic [13] can be seen as 
a systematic way of generating the verification conditions which ensure that an 
annotated program indeed constitutes a proof outline. A verifying compiler then 
consists of a front-end tool to a theorem prover which checks the automatically 
generated verification conditions (see for example [7]). 

Obviously, to be useful in practice Hoare logics should, first of all, be sound, 
i.e., only correct programs should be provably correct. Gonversely, completeness 
means that all correct programs are provably correct. Its practical relevance, 
apart from providing a firm formal justification, is that in case we cannot prove 
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our program correct, we know that this is due to incorrectness of our program 
(which in practice is most frequently the case). An incomplete proof method 
does not allow this simple inference. 

Furthermore, to be useful in practice Hoare logics should allow the specifica- 
tion and verification of a program at the same level of abstraction as the pro- 
gramming language itself. This requirement has some important consequences 
for the specification of programs which involve dynamically allocated variables 
(e.g., ‘pointers’ or ‘objects’). Firstly, this means that, in general, there is no 
explicit reference in the assertion language to the heap which stores the dynam- 
ically allocated variables at run-time. Moreover, it is only possible to refer to 
variables in the heap that do exist. Variables that do not (yet) exist never play 
a role. 

The main contribution of this paper is a recipe for complete Hoare logics for 
reasoning about closed object-oriented programs at an abstraction level which 
coincides with that of object-oriented languages in general. This recipe is based 
on the transformational approach as introduced and applied in [18]: we first 
present a new completeness result of a Hoare logic for what is basically a proce- 
dural language with dynamically allocated variables. This result itself involves a 
non-trivial generalization of Gorelick’s basic completeness result of the standard 
Hoare logic for recursive procedures with simple variables only ([11]). Then we 
show how this completeness result can be further generalized to existing Hoare 
logics for typical object-oriented concepts like method calls, sub-typing and in- 
heritance by transforming an encoding of these concepts into this procedural 
language with dynamically allocated variables. 

Proving Completeness 

Below we summarize Gorelick’s seminal completeness proof for recursive pro- 
cedures with simple variables to clarify the context of the crucial steps in the 
enhanced proof. 

Gonsider a simple sequential programming language with (mutually) recur- 
sive (parameterless) procedures. Let 

Pi ^ * 5 * 1 , ... , Pn ^ Sn 

be a set of mutually recursive procedure definitions, where p ^ S indicates that 
the statement S is the body of procedure p. Gentral to the completeness proof 
is the Most General (correctness) Formula (MGF) of a statement S', which is a 
formula of the form 

{x = z}S{SP(S, X = z)}. 

Here, ^ = zi , . . . , is a sequence of logical variables (not occurring in state- 
ments) that correspond with the program variables x = x\,...,Xn of S. The 
precondition x = z, which abbreviates the conjunction of the equalities Xi = Zi, 
for i = 1, ... ,n, states that the (initial) values of the program variables are stored 
in the corresponding logical variables. For this reason, these logical variables are 
called ‘freeze’ variables. The postcondition SP(S, ir = z) describes the strongest 
postcondition of the statement S with respect to the precondition x = z. 
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The completeness proof in [11] shows that every valid correctness formula 
{PjS'lQ} can be derived if we first prove the most general correctness formula 
{x = z}pi{SP{pi,x = z)} of every procedure Pi. In the sequel, we denote this 
formula by (for i = l,...,n). The above claim is proved by induction on 
the complexity of S. The most interesting case where S equals pi, for some 
i = 1, . . . , n, requires an application of the invariance axiom: 

{P[z/x]}p,{P[z/x]}. 

Here P[z/x\ denotes the result of replacing the program variables by their 
corresponding logical variables. By the conjunction rule this is combined with 
<l>i to obtain 

{P[z/x\ A X = z}pi{P[z/x] A SP(pi, X = z)}. 

From the validity of the given correctness formula {P}pi{Q} and the defini- 
tion of the strongest postcondition one then proves the validity of the assertion 

P[z/x] A SP{pi, X = z) ^ Q. 

This formula and the consequence rule allows us to replace the postcondition 
by Q. By applying a substitution rule and the rule of consequence we finally 
change the precondition to P and obtain {P}pi{Q}. 

The final step in the proof consists of deriving the MGF of every procedure 
call Pi (that is, <Pi) in the logic by means of the recursion rule 

Fi, . . . , h {Pl}Si{Qi}, {Pn}Sn{Qn} 

Fi 

Here, Fi denotes {Pi}pi{Qi}, for z = 1, . . . , n. Since 
{x = z}S'i{SP(pi, X = z)} 

(with Si the body of Pi) is by definition a valid correctness formula, we have as 
a particular case of the above, its derivability from <?i, . . . The above rule 
then allows us to conclude <Pi, for i = 1, . . . ,n, thus finishing the completeness 
proof. 

Our generalization of the above requires an intricate analysis of some general 
characteristics of correctness proofs for a procedural language with dynamically 
allocated variables. First, we have to formulate an assertion corresponding to 
X = z which ‘freezes’ an initial state. In our setting, a state describes the heap 
which cannot captured statically by a finite number of variables. Next, we ob- 
serve that the above invariance axiom as such is also not valid because the 
creation of new variables (or objects in object-oriented jargon) affects the scope 
of quantified logical variables. Therefore, creation of new variables in general 
will affect the validity of an assertion even if it does not refer to program vari- 
ables at all. Summarizing, dynamically allocated variables basically require a 
proof-theoretical reconsideration of the concepts of initialization and invariance. 
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Below, the operator op is an element of Op, the language-specific set of op- 
erators, and m is an arbitrary identifier. 

Table 1. The syntax of the programming language 



e G Expr 


:= y 1 op(ei,...,e„) 


y G Var 


;= u 1 e.x 


s G SExpr 


:= new C() m(ei, . 


S G Stat 


■■= y = e -,\y = s ;\ while (e) { 5 } 
1 S' S' 1 if (e) { S' } else { S } 


meth G Meth 


:;= m(ui, . . . , Un) { S return e ; } 


7T G Prog 


:;= class* 



The results of the transformational approach then justifies our conclusion that 
Hoare logic for object-oriented programs basically boils down to a formalization 
of dynamically allocated variables. 

Plan of the Paper 

This paper is organized in the following way. Section 2 and 3 introduce a proce- 
dural programming language with dynamically allocated variables and the asser- 
tion language. In Section 4 we outline the corresponding Hoare logic. Section 5 
contains the completeness proof. In Section 6 we introduce the transformational 
approach and sketch briefly some of its applications to typical object-oriented 
concepts. In the last section we draw some conclusions. 



2 A Procedural Language with Dynamically Allocated 
Variables 

The syntax of the basic strongly typed programming language considered in this 
paper is described in Table 1. We only consider the built-in types boolean and 
int. We assume given a set C of class names, with typical element C. The set 
of (basic) types T is the union of the set {int, boolecui} and C. In the sequel, t 
will be a typical element of T. 

We assume given a set TVar of typed temporary (or local) variables and a set 
IVar of typed instance variables. Instance variables belong to a specific instance 
of a class and store its internal state. Temporary variables belong to a method 
and last as long as this method is active. A method’s formal parameters are also 
temporary variables. We use u and x as typical elements of the set of temporary 
variables and the set of instance variables, respectively. We denote by |m] and |a;] 
the (static) type of the temporary variable u and instance variable x, respectively. 
A variable y is either a temporary variable or a navigation expression e.x. A 
navigation expression e.x, with C the static type of e, refers to the value of the 
variable x of the instance e of the class C. 

A program is a finite set of classes. A class defines a finite set of procedures 
(or methods in object-oriented jargon). A method m consists of its formal pa- 
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rameters u\, . . . ,Um a statement S, and an expression e without side effects 
which denotes the return value. We have the usual assignments y = e without 
side effect and y = s with side effect. A variable y of type C, for some class C, 
can be dynamically allocated by means of an assignment y = new C() which 
involves the creation of an instance of class C. An assignment y = m(ei, . . . , e„) 
involves a call of method m with actual parameters ei, . . . , e„. 

Observe that our language does not support constructor methods. Therefore, 
an expression like new CO will call the default constructor method, which will 
assign to all instance variables their default value. 

2.1 Semantics 

In this section, we will only describe the overall functionality of the semantics 
of the presented language because this suffices to understand the completeness 
proof. 

Each instance of a class (or object in object-oriented jargon) has its own 
identity. For each class C G C we introduce therefore an infinite set dom(C) of 
identities of instances of class C, with typical element o. For different classes 
these sets of object identities are assumed to be disjoint. By O we denote the 
union of the sets dom(C). For t = int, boolean, dom(t) denotes the set of 
boolean and integer values, respectively. 

A configuration cr (also called the heap) is a partial function that maps each 
existing object to its internal state (a function that assigns values to the instance 
variables of the object). Formally, a is an element of the set 

S= 0 ^ n dom(|a;]). 

fcGiVar 

Here Oie/ denotes a generalized cartesian product over an index set I. In 
this way, cr(o), if defined, denotes the internal state of an object, i.e., a(o)(x) 
denotes the value of the instance variable x of the object o. It is not defined for 
objects that do not exist in a particular configuration a. Thus the domain of 
a specifies the set of existing objects. We will only consider configurations that 
are consistent. We say that a configuration is consistent if no instance variable 
of an existing object refers to a non-existing object. 

On the other hand, a temporary context 7 specifies the values of the tempo- 
rary variables of the executed method: 7 is a typical element of the set 

r= n dom(|M]). 

it^TVar 

The value of a temporary variable u is denoted by 'y(u). 

A state is a pair (cr, 7), where the temporary context 7 is required to be 
consistent with the configuration cr, which means that all temporary variables 
refer to objects that exist in cr. 

Given a set of class definitions the semantics of statements is given by the 
(strict) function: 

5 : Stat ^ (A X T)_l ^ (A x T)_l, 
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such that 5(S')((J, 7) = indicates that the execution of S in the configu- 

ration (17,7) terminates in the configuration (cr',7'). Divergence is denoted by _L. 
A compositional characterization of 5 - which is fairly standard - can be given 
following [ 5 ]. 

In this paper we only need the following semantic definition of a method call 
y = m(ei, . . . , e„), with method body S. We have that 

S{y = m{ei,...,en)){(J,j) = (cr',7') 



if 

5(S')(cr,7o) = (ct",7") 

where 



— 7o results from 7 by assigning to the formal parameters of m the values of 
the actual parameters Ci, . . . , e„ in (ct, 7); 

— (cr',7') results from (cr",7) by assigning the value of the result expression 
e in (cr",7") to the variable y (which either will affect 7, in case of a local 
variable, or cr", in case of a navigation expression). 



3 The Assertion Language 

In this section we present an assertion language for the specification of properties 
of dynamically evolving object structures. We want to reason about these struc- 
tures on an abstraction level that is at least as high as that of the programming 
language. In more detail, this means the following: 

— The only operations on “pointers” (references to objects) are 

• testing for equality 

• dereferencing (looking at the value of an instance variable of the refer- 
enced object) 

— In a given state of the system, it is only possible to mention the objects that 
exist in that state. Objects that do not (yet) exist never play a role. 

The above restrictions have quite severe consequences for the proof system. 
The limited set of operations on pointers implies that first-order logic is too 
weak to express some interesting properties of pointer structures like reachability. 
Therefore we have to extend our assertion language to make it more expressive. 
We will do so by allowing the assertion language to reason about finite sequences 
of objects. 

The set of logical expressions in the assertion language is obtained by sim- 
ply extending the set of programming language expressions without side effect 
(Expr) with logical variables. Logical variables are used for quantification and 
for reasoning about the constancy of program expressions. In the sequel, z will 
be a typical element of the set of logical variables LVar. Logical variables can 
also have a sequence type t*, for some t G T. In such a case, its value is a finite 
sequence of elements of type t. 
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The syntax of the assertion language is summarized as follows. 

I G LExpr ::= u \ z \ Lx \ ±f Iq then li else I 2 f i | op(li, 

P,Q € Ass ::= h = h \ ~^P \ P f\Q \3z ■. t{P) 

(we omit typing information: e.g., the expression I in l.x should refer to an object 
of some class and only boolean expressions can be used as assertions). 

The conditional expression is introduced in order to reason about aliases, i.e., 
variables which refer to the same object. To reason about sequences we assume 
the presence of notations to express the length of a sequence (denoted by \l\) 
and the selection of an element of a sequence (denoted by l[n], where n is an 
integer expression) . More precisely, we assume in this paper that the elements of 
a sequence are indexed by 1, . . . , n, for some integer value n > 0 (the sequence is 
of zero length, i.e., empty, if n = 0). Accessing a sequence with an index which 
is out of its bounds results in the value T. 

Only equations are allowed as basic assertions. This allows us to remain 
within the realm of a two- valued boolean logic, as explained in more detail 
below. 

As stated above, quantification over finite sequences allows us to specify 
interesting properties of the heap. For example, that two objects hd and tl are 
connected in a linked list. This is asserted by the formula 



B z : C* {z[V\ = hd A z[\z\] = tl A 

V i : int(l <it\i<\z\^ 2;[i].next = z[i + 1])). 



Here z is a logical variable ranging over finite sequences of objects in class C 
and next is an instance variable of class C . 

Logical expressions are evaluated in a configuration a, a temporary context 7, 
and a logical environment to, which assigns values to the logical variables. The 
logical environment should also be consistent with the configuration cr in the 
sense that no logical variable should refer to a non-existing object. The resulting 
value is denoted by £(l)(cr, 7, w). By £(^)(cr, 7, w) = T we indicate that the value 
of the expression is undefined (e.g., dereferencing the null-pointer, division by 
zero, etc.). The definition of C is rather standard and therefore omitted. 

The resulting boolean value of the evaluation of an assertion P is denoted by 
A{P){a,j,uj). We define 



A{h = ^2)(ct,7,w) 



true if A(?i)(ct, 7 ,u;) = A(?2)(o-,7, w) 
false otherwise 



Assuming the constant nil for denoting the value T, we can can assert that 
the value of an expression e is undefined simply by the equation e = nil. 

As already explained above, a formula 3z : C{P) states that P holds for 
an existing instance of class C . Thus the quantification domain of a variable 
depends not only on the (static) type of the variable but also dynamically on the 
configuration. Similarly, a formula 3z : C*{P) states the existence of a sequence 
of existing objects (in class C). 
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The notation cr, 7,w |= P means that A{P){a,j,tj) ~ true. An assertion 
P is valid, denoted by ^ P, if ct, 7,w \= P for every state (ct, 7), and logical 
environment uj which are consistent w.r.t. the existing objects of a, i.e., instance 
variables of existing objects, temporary variables and logical variables refer only 
to existing objects. 

It is worthwhile to observe that quantification over finite sequences implies 
that the logic is not compact [8] (and as such transcends the realm of first-order 
logic) because we can express that there exists a finite number of objects (in a 
given class C): The assertion 

3z : C*Vv : C3n : int(v = z[n\) 

states that there exists a finite sequence that stores all (existing) objects in class 
C. 

Furthermore, we observe that the domain of discourse of our assertion lan- 
guage consists only of the built-in data types of the integers and booleans, and 
the program variables, i.e., it excludes the methods. This allows for a clear sep- 
aration of concerns between what a program is supposed to do as expressed by 
the assertion language and how this is implemented as described by its methods. 



4 The Proof System 

Given a set of class definitions, correctness formulas are written in the usual form 
{PjS'lQ}, where P and Q are assertions and S' is a statement. We say that a cor- 
rectness formula {P}S{Q} is true w.r.t. a state (cr, 7) and a logical environment 
oj, written as cr, 7,w |= {P}S{Q}, if 17,7,0' \= P and S(S)(ct, 7) = (17,7') implies 
^ Q. This corresponds with the standard partial correctness interpre- 
tation of correctness formulas. By \= {P}S{Q}, i.e., the correctness formula 
{P}S{(5} is valid, we denote that cr, 7,0; \= {P}S{Q}, for every state (cr, 7) 
and logical environment ui which are consistent. Finally, F {P}S{(3} denotes 
derivability of {P}S{(5} in the logic. 

We only discuss the rules for method invocations in detail. The axioms for the 
other statements of our basic language are already introduced in, for example, 
[7]. Here, we will only give a brief description of these axioms. They all involve 
substitution operations that compute the weakest precondition of a statement. 
By a standard argument this implies that we can derive all valid specifications 
of such statements. For this reason, we focus on reasoning about methods invo- 
cations in this paper. 

For an assignment to temporary variables, we have the usual axiom 

{P[e/u]} u = e {P}, 

where P[e/u] denotes the result of replacing every occurrence of the temporary 
variable u in P by the expression e. Soundness of this axiom is stated by the 
following theorem. 
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Theorem 1. We have 

(7, 7,w 1= P[e/u] if and only if ,ui |= P, 
where 7' results from 7 by assigning £(e)(cr,'y,oj) to u. 

Proof. Standard induction on the complexity of P. 

We have a similar theorem for the substitution of logical variables. 
Theorem 2. We have 

1= P[e/z] if and only if ct, 7,0;' |= P, 
where lo' results from to by assigning £(e)(a,'y,oj) to z. 

In the axiom 

{P[e' /e.x]} e.x = e' {P} 

for assignments to instance variables the substitution operation [e'/e.x] differs 
from the standard notion of structural substitution. An explicit treatment of 
possible aliases is required for this type of assignments. Possible aliases of the 
variable e.x are expressions of the form l.x: After the assignment it is possible 
that I refers to the object denoted by e, so that l.x is the same variable as e.x 
and should be substituted by e'. It is also possible that, after the assignment, I 
does not refer to the object denoted by e, and in this case no substitution should 
take place. Since we can not decide between these possibilities by the form of the 
expression only, a conditional expression is constructed which decides ’’dynam- 
ically”. Let I' denote the expression l[e'/e.x]. If p] = |e], i.e., the expressions I 
and e refer to objects of the same class, we define (Lx)[e'/e.x] inductively by 

±f I' = e then e else I' .x f i 

In case the types of the expressions I and e do not coincide, i.e., they do not 
refer to objects of the same class, aliasing does not occur, and we can simply 
define {l.x)[e' / e.x] inductively by V .x. 

Soundness of the above axiom for assignments to instance variables is stated 
by the following theorem. 

Theorem 3. We have that 

cr, 7,a> 1= P[e' ! e.x] if and only if ct', 7 ,w |= P, 

where a'(o)(x) = £(e')(a,j,cv), for o = £(e)(cr, 7, w), and in all other cases a 
agrees with a' . 

Proof. Induction on the complexity of P (for details see [21]). 
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In [7] we also discuss the substitution operation [new C /u], which computes 
the weakest precondition of an assignment u = new CO involving a temporary 
variable u. The definition of this substitution operation is complicated by the 
fact that the newly created object does not exists in the state just before its 
creation, so that in this state we can not refer to it! We however are able to 
carry out the substitution due to the fact that this variable u can essentially 
occur only in a context where either one of its instances variables is referenced, 
or it is compared for equality with another expression. In both of these cases 
we can predict the outcome without having to refer to the new object. Another 
complication dealt with by this substitution operation is the changing scope of 
a bound occurrence of a variable 2; ranging over objects in class C which is 
induced by the creation of a new object (in class C). For example, we define 
3z : C(P)[new C/u] by 

3z : C(P[new C/u]) V (P[w/z][new C/u\). 

The first disjunct 3z : C(P[new C/u]) represents the case that P holds for 
an ‘old’ object (i.e. which exists already before the creation of the new object) 
whereas the second disjunct P\u / z][r\e\N / u\ represents the case that the new 
object itself satisfies P. Since a logical variable does not have aliases, the sub- 
stitution [u/ z] consists of simply replacing every occurrence of z by u. 

Given this substitution we have the following axiom for object creation in- 
volving a temporary variable: 

{P[new C/u]} u = new C() {P|. 

Soundness of this axiom is stated by the following theorem. 

Theorem 4. We have 

a,^,LU 1= P[new/u] if and only if |= P, 

where o' is obtained from a by extending the domain of a with a new object o 
and initializing its instance variables. Furthermore the resulting local context 7' 
is obtained from 7 by assigning o to the variable u. 

Proof. The proof proceeds by induction on the complexity of P (for the details 
we refer to [21]). 

Observe that an assignment e.x = new C() can be simulated by the sequence 
of assignments u = new C(); e.x = u. Therefore we have the axiom 

{P[u/e.a;][new C/u]} e.x = new C() {P}, 

where u is a fresh temporary variable which does not occur in P and e. Note 
that the substitution [u/e.x] makes explicit all possible aliases of e.x. Soundness 
of this axiom follows from the above. 

It is worthwhile to observe that aliasing and object creation are phenomena 
characteristic of dynamically allocated variables. Furthermore, the above substi- 
tutions provide a formal account of aliasing and object creation at an abstraction 
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level which coincides with that of the programming language, e.g., without any 
explicit reference to the heap. 

We now turn to method invocations. Suppose we have in class C a method 
m(ui, . . . ,Un) { S return e }. The following rule for method invocation (MI) 
allows to derive a correctness specification of a call y = m(ei, . . . ,e„) from a 
correctness specification of the body S of m. 

{P}S'{Q[e/rejturn]} Q[J/z] R[retnrn/y] 

{P[e/u][f/z]}y = m{ei,...,en) {i?} 

Here we do not allow temporary variables in Q. Except for the formal pa- 
rameters ui, . . . ,Un, no other temporary variables are allowed in P. 

The simultaneous substitution \e/u] models the assignment of the actual 
parameters e = ei, . . . , e„ to the formal parameters u = u\, . . . ,Un- 

The substitution [e/return] applied to the postcondition Q of S' in the first 
premise models a (virtual) assignment of the result value to the logical variable 
return, which must not occur in the assertion R. The substitution [return/y] 
applied to the postcondition R of the call models the actual assignment of the 
return value to y. It corresponds to the usual notion of substitution if y is 
a temporary variable. Otherwise, it corresponds to the substitution operation 
[e'/e.x] for reasoning about aliases. 

It is worthwhile to observe that the use of the additional return variable 
allows to resolve possible clashes between the temporary variables of the post- 
condition R of the call and those possibly occurring in the return expression e. 
As a typical example, consider the object-oriented keyword this, which denotes 
the current active object, as an additional parameter of each method. We observe 
that, in case a method returns the identity of the callee, in the postcondition 
i?[this/y] of the caller, this, however, would refer to the caller. 

Next, we observe that a temporary expression / of the caller generated by 
the following abstract syntax 

f ::=u\ op(/i, ...,/„) 

is not affected by the execution of S by the receiver. A sequence of such ex- 
pressions / can be substituted by a corresponding sequence of logical variables 
z of exactly the same type in the specification of the body S. Thus the rule re- 
flects the fact that the values of such expressions do not change by the execution 
of the call. Without these substitutions one cannot prove anything about the 
temporary state of the caller after the method invocation. 

The generalization of the rule for non-recursive method invocations to one for 
(mutually) recursive method invocations follows the standard pattern. The idea 
is to assume correctness of the specification of the method call while proving 
the correctness formula of the body. In case of mutually recursive methods, we 
may assume correctness of the specification of several method calls. But this also 
forces us to prove the corresponding specifications of the bodies of all these calls. 
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The rule schema for mutually recursive method invocations (MRMI) is as 
follows. 



where 



Ii, . ■ . ,Ik Ai, . . . , Ak\- Fi, . . . ,Fk 

Fi 



(MRMI) 



— Ai is a specification of a call, i.e., for t = 1, . . . , fc, Ai denotes a correctness 
formula 

{Pi[ei/ui][fi/zi\} yi = m,{ei) {R,} 

with Ui the formal parameters of method and e* a corresponding sequence 
of actual parameters and; 

~ Fi is a correctness formula 

{Pi} Si {Qi[ei/ret\n:ni]} 

with Si the body of method mp and its return expression; 

— Ii denotes the implication 

Qi[Ii/zi] R*[returnj/yj] 

which relates he postconditions of the call and the body. 

The syntactical restrictions of rule (MI) also apply to all assertions in this 
rule. 



5 Completeness 

In this section, we will prove (relative) completeness of the logic [4] (soundness 
follows from a standard inductive argument). That is, given a finite set of class 
definitions, we prove that ^ {PjS'lQ} implies h {PjS'lQ}, assuming as addi- 
tional axioms all valid assertions. We do so following the structure of the proof 
that is given in the introduction. In the following sections we give solutions for 
each of the issues that were mentioned in the introduction. 

First we show how to formulate an assertion that freezes the initial state. Sub- 
sequently, we give an enhanced version of the invariance axiom. As a counterpart 
of the substitution [z/x\ in the invariance axiom, we define a substitution that 
modifies an assertion in such a way, that its validity is not affected by execution 
of any object-oriented program. In particular, it is immune to object-creation. 
Next, we show that the our technique for freezing the initial state leads to Most 
General Formulas about method calls that enable us to derive any valid correct- 
ness formula. Finally, we show how to derive these MGFs for method calls. 

Definition 1. Our completeness proof is based on the following standard se- 
mantic definition of the strongest postcondition SP(5', P) as the set of triples 
(ct,7,w) such that for some initial state (cr',7') we have 5(5')(cr', 7') = (17,7) 
and cr', 7', oj \= P. 
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It can be shown in a straightforward although rather tedious manner that 
SP(S', P) is expressible in the assertion language (see [6, 23]). The main idea fol- 
lowed in [6] is based on a logical encoding of states as described in the next section 
which heavily relies on the presence of quantification over finite sequences. 

At several points in the completeness proof, we have to refer to the set M{S) 
of method calls that might be executed as a result of executing S. This set M{S) 
is defined as the smallest set which satisfies: 

— y = rn{ei, . . . , e„) € M{S) if y = m(ei, . . . , e„) occurs in S 

— M{S') C M{S) if if y = m(ei,...,e„) G M{S), where S' is the body of 
method m. 



5.1 Freezing the Initial State 

The first problem is to freeze the initial state which consists of the internal 
states of the existing objects and the values of the temporary variables. The set 
of existing objects is not statically given. Therefore we store the existing objects 
of a class C ‘dynamically’ in a logical variable seq^ of type C*. For storing the 
values of instance variables, we introduce for each class C and instance variable 
X G IVar a corresponding logical variable 0{C,x) of type |x]* such that the 
value of the instance variable x of an existing object of class C is stored in the 
sequence denoted by 0{C,x) at the position of the object in seq^. Storing the 
initial values of the temporary variables of the active object in logical variables 
is straightforward. We simply introduce a logical variable 0{u) of type |u], for 
each temporary variable u. Figure 1 pictures the relation between the heap and 
its representation in the logical state (here C represents the sequence of existing 
objects in class C and X a sequence storing all the values of the instance variable 
x). 

The above encoding of a configuration can be captured logically by a finite 
(we assume given a finite set of class definitions) conjunction of the following 
assertions: 

— Vz : C{3i{z = seq^-)*])) 

which states that the sequence seq<^ stores all existing objects of class C. 

— Vi(seq<^[t].x = 0{C,x)[i\) 

which states that for each position in seq^ the value of the instance variable 
x of the object at that position is stored in the sequence 0(C, x) at the same 
position. 

~ u = 0{u) 

which simply states that the value of u is stored in 0{u). 

The resulting conjunction we denote by init. 

In the remainder of this section, we will work towards a new invariance axiom 
that replaces the old axiom 



{P[z/x]}S{P[z/x]}. 
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Fig. 1. Freezing the Initial State 

We start by introducing a counterpart of the substitution \zjx\. Note that 
this substitution replaces program variables by their logical counterparts as in- 
troduced above. We therefore want to extend the mapping O to assertions such 
that it replaces all references to program variables by their logical counterparts. 
Since in general we cannot statically determine the position of an object of class 
C in the sequence seq^ we ‘skolemize’ the assertion Vz : C{3i{z = seq<^[i])) by 
introducing for every class C a function posq{1) which satisfies the assertion 

Vz : C{z = seqc[posc(z)]). 

Note that in practice assertion languages should allow the introduction of 
user-defined functions and predicates. 

We have the following main case of the transformation 0 on logical expres- 
sions I (using postfix notation) . 

{l.x)0 = 0{C, a;)[poS(;7(Z0)] 

where C = |Z]. As a simple example we have that {u.x)0 yields the expression 
6>((7, 3 ;)[posc(0(m))], where C is the static type of the temporary variable u. 

Quantification requires additional care when extending O to assertions be- 
cause the scope of the quantifiers in general will be affected by object creation. 
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This can be solved by restricting quantification to the objects that exist in the 
initial state. That is, by restricting quantification to objects in seq^. Therefore 
we introduce the following hounded form of quantification: 

(3z : C{P))0 = 3z : C{z G seq^ A P0) 

{3z : C*\P))0 = 3z : C*{z Q seq^ A P0) 

The assertions z G seq,^ and 2 ; C seqj;; stand for 3i(z = seq(;;;[i]) and 
'ii3j{z[i] = seq<^[j]). Note that the assertion 3i{z = seq(^[t]) states that the 
object denoted by 2 ; appears in the sequence denoted by seqj;^. The assertion 
'ii3j{z[i] = seq(^[j]) states that all objects stored in the sequence denoted by z 
are stored in the sequence seq^. We thus restrict quantification to the sequences 
seq<^. (For quantification over basic types or sequences of basic types we simply 
have {3zP)0 = 3z{P0).) 

The transformation 0 is truth-preserving in the following manner. 

Theorem 5. For every assertion P, and any state (cr,'y) and logical environ- 
ment oj which are consistent, we have that ^ init implies cr, 7 , w \= P iff 

h P0. 

Proof. By structural induction on P. □ 

The following theorem states that we can prove that P0 is an invariant for 
every statement S and assertion P. Thus this theorem can replace the invariance 
axiom. 

Theorem 6. For any statement S and assertion P we have h {P0} S {P0}. 

Proof. The main idea behind the proof is that P0 is immutable to all substitu- 
tions in the proof rules since the transformation 0 replaces all program variables 
by logical variables. Let P' denote P0. 

Since P' does not contain any program variables, clearly we have that P'[e/u] 
and P'[e'/e.x] both equal (syntactically) P', for any substitutions [e/rt] and 
[e'/e.x]. 

Moreover, since all quantification in P' is bounded we have that P' [new C /u] 
is logically equivalent to P'\ By the soundness of the axiom for object creation 
(as stated in Theorem 4) we have that cr, 7 , 0 ; \= P'[new C/u] if and only if 
a' ,'y' ,L 0 ^ P' , where a' results from adding to the domain of cr a new instance of 
class C and 7 ' results from assigning the identity of this newly created instance 
to the temporary variable u. Since u does not appear in P', it follows that 
cr', 7 ', w \= P' if and only if cr', 7 , w \= P' . Finally, since the newly created object 
in class C does not appear in a;(seq^) (note that by definition a>(seq(^) may refer 
only to objects existing in cr) and all quantification in P' involving this newly 
created object is restricted to ^(seq,^) it follows that ct', 7 ,w |= P' if and only if 
Cr,7,W h P'- 
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5.2 Most General Correctness Formula 

In the previous section, we described a way to freeze the initial state of an 
object-oriented program. The information about the initial state was captured 
by the formula init. With this formula we can define the most general correctness 
formula (MGF) of an object-oriented statement. It is the formula 

{init}S'{SP(S', init)}. 

In this section, we will show that assuming that the MGF holds for every 
method invocation in the program suffices to derive every valid correctness for- 
mula, as stated by the following theorem. 

Theorem 7. If \= {PjS'lQ} we have 

A^,...,Ak^{P]S{Q}, 

where Ai = {init}S'i{S'P(5'j, init)}, for i = 1, . . . , fc, and M{S) = {S'!, . . . , 5*^}. 

The proof proceeds by structural induction on S. The theorem holds for 
assignments y = e and y = new (C) because the soundness of their axioms in fact 
show that the corresponding substitutions compute the weakest precondition. 
Gomplex control structures are treated in a standard manner ([3]). The following 
lemma describes the most interesting case of a method call. 

Lemma 1. For every call S = y = m(ei, . . . , e„) we have 

\= {P}S'{(3} implies {init}S'{SP(S', init)} F {P}5'{(5} 

Proof. For technical convenience only we assume that P and Q do not contain 
free occurrences of the logical variables 0{u) and 0{C,x) (otherwise we first 
have to rename them). By Theorem 6 we have F {P0}S{P0}. An application 
of the conjunction rule gives us the correctness formula 

F {P0 A init}S'{P0 A SP(5', init)}. 

Our next step is to prove 

1= P0 A SP(S', init) ^ Q. 

Let cr,^,oj ^ P0 A SP(5', init). By the definition of SP there exists an initial 
configuration (cto, 7 o) such that both (To, 7 o,w |= init and 5 (S')(cto, 70) = (c, 7) 
hold. 

Next, we show that (Tq, 70, w P0 leads to a contradiction in order to obtain 
(To, 7o, w \= P0. So let (Jo,7o, w ^ P0. By Theorem 6 we have F {^P0}S'{^P0}. 
Soundness of the proof system ensures that we also have \= {^P0}S{^P0}. 
This implies that p^ which contradicts an earlier assumption. 

By (To,7o,w \= P0 and Theorem 5 we arrive at cro,7o,w |= P. Since ^ 
{P}S'{(5} we conclude that cr, 7,a> ^ Q. So we can proceed by an application of 
the consequence rule to obtain 



F {P0Ainit}S'{g}. 
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Next, we can apply the standard rules which allow one to replace in the 
precondition every logical variable 0(u) by the temporary variable u and ex- 
istentially quantifying all the logical variables 0{C,x) (x an arbitrary instance 
variable in an arbitrary class C). Finally, we existentially quantify the variables 
seq,^, for every C. It is not difficult to prove that the assertion P logically im- 
plies the resulting precondition. Therefore an application of the consequence rule 
finishes the proof. 

The final step in the completeness proof is to show that we can derive the 
correctness formula 

{init}5'{SP(5', init)} 

for any assignment S = y = m(ei, . . . , e„) that involves a method call. 
Theorem 8. For any assignment S = y = m(ei, . . . , e„) we have 

h {init}S'{SP(S', init)}. 

Proof. We use the following notational conventions in this proof. Let 

M(5) = {5i,...,^4, 

with Si = yi = TOi(e}, . . . , for i = 1, . . . , fc. Let Sq denote y = m{e \, . . . , e„). 
Let Tli, for t = 0, . . . , n, denote the correctness formula 

{init}S'i{SP(S'i, init)}. 

Let for i = 0, . . . , n, denote the body of rrii and let be its return 
expression. The expression ei abbreviates the sequence e},...,e)j.. We denote 
the formal parameters u \, of method nii by Ui . 

We must prove h {init}S'{SP(S', init)}. By the rule (MRMI) and Theorem 7 
it suffices to find, for i = 1, ... ,k, valid correctness formulas 



{Pi} S[{Qi[eJretu-rni]}, (1) 

such that 

\=imt ^ Pi[eilui][Jilzi], (2) 

and 

h Qi[fi/zi] SP(S'i,init)[returni/?/i], (3) 

for some substitutions [fi/zi]. Observe that Theorem 7 requires us to prove 
validity, not derivability. The substitutions [fi/zi] involve temporary expressions 
fi and corresponding logical variables satisfying the conditions of rule (MRMI) . 

Obvious candidates for the assertions Pi and Qi are the formulas init and 
SP(S'j,init)[returiii/?/i], respectively. However, for (2) and (3) to be valid we 
introduce a renaming function which transforms any temporary variable u 
into a (new) logical variable <P(u) of the same type. Note that applying <I> to any 
assertion effectively neutralizes the passing of the actual parameters. That is. 
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{P<P)e = P4> 

for every assertion P and substitution 6 which only transforms temporary 
variables. So candidates for Pi and Qi are init^ and SP(S'i,init)[returni/yi]<?, 
respectively. Using the inverse of ^ for [fi/zi], we trivially obtain (2) and (3). 

However, to prove the validity of the correctness formulas in (1) we have to 
strengthen init^ with additional information about the actual parameters spec- 
ified by the call Si. After the invocation of the method the formal parameters 
should have the values of the actual parameters. This information is given by 
the conjunction of the equations uj = (ej^), for j = 1 , . . . , n^. Observe that (2) 
still holds because 

[u] = yields e] = e]. 

Summarizing, for the assertion Pi defined by 

7li 

init^ S f\Uj = 
i=i 

we can now prove the validity of the correctness formula 

{Pi} {Qi[e»/returni]}. 

The proof proceeds as follows: let |= Pi and 5(S'Q(cr, 7) = (cr',7'). We 

extend this computation of the method body S'- to one of the call Si', we define 
the initial local context 70 of the call Si by assigning w(^(u)) to every temporary 
variable u, i.e., 7 o(m) = w(^(u)). From ^ init<? we derive cr, 70, w |= initi 

(formally this follows from Theorem 2). Furthermore, from ^ m* = (e*^) 

it follows that the value of the actual parameter e*, with j = 1, . . . ,nj, in the 
configuration (a, 70) of the call equals the value of the corresponding formal pa- 
rameter u* in the configuration (a, 7) of the method body (formally this follows 
from Theorem 1) . 

The final state of the call (cr", 7o) can be obtained by assigning the value 
of the result expression Cj to the variable jji. We must consider two options, 
because yi can be either a navigation expression or a temporary variable. If yi 
is a navigation expression of the form e.x, we have Jq = 70, i.e., the initial local 
context of the call is not affected by the return, and a” is obtained from o' by 
assigning the value of the return expression e* in the state (ct', 7') to the instance 
variable x of the object denoted by e. If yi is a temporary variable m, we define 
a" = cr', i.e., the return does not affect the /leap, and 7 q is obtained from 70 by 
assigning the value of the return expression Cj to the temporary variable u. 

From the semantics of method calls is described in Section 2. lit follows that 

5(5'*) (cr, 70) = (cr", 7o). 

Since ct, 7o,w |= init, we have by Definition 1 that cr", 7 q,u; ^ SP( 5i,init). 
Next, let oj' be obtained from uj by assigning the result value, i.e., the value 
of j/iin the configuration (cr", 7 q) of the call, to the logical variable return^. It 
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follows that cr", 7 g,a;' \= SP(S'i,init)[returni/j/i]. Observe that the truth of the 
assertion SP(S'j,init)[returni/yi]<? does not depend on the local context or the 
variable yi due to the substitutions [returni/j/i]^. So we have 

1= SP(S'i,mit)[returni/yi]^. 

Finally, because of the definition of w' (note that w(returni) equals the value 
of the return expression e* in state (ct', 7 ')) we conclude 

cr', 7 ',w ^ SP(S'i,init)[returni/i/i]^[ei/returni]. 



6 The Transformational Approach 

In this section we introduce a general methodology for generalizing our complete- 
ness result to more advanced object-oriented concepts. Our methodology is based 
on the transformational approach introduced in [18]. Given an object-oriented 
extension of our very simple object-oriented language C, this transforma- 
tional approach consists of the definition of a translation 

T:C+^C 

such that for every statement S in we have 

{P}5{g} iff {P}T{S){Q}, 

for every precondition P and postcondition Q. A complete Hoare logic for 
thus can be derived by transforming the translation T into corresponding proof 
rules. 

Let us apply this approach first to the proof rule MI for method calls. Consider 
the translation of statements in our language C which transforms every object- 
oriented method call 



eo.m(ei, . . . , G-n') 

into the procedural call 

^(^ 0 ? ■ ■ ■ 5 ^n) 1 

where the typical object-oriented concept of this is simply viewed as an addi- 
tional formal parameter of the method m. We thus obtain the following new rule 
for typical object-oriented method invocations y = eo.m(ei, . . . , Cn). 

{P}5'{g[e/return]} Q[f/z] j^[return/y] 

{P[e/u][f/z]} y = eom(ei, . . . ,e„) {i?} 



where [e/rt] abbreviates the substitution [eg, ei, . . . , e„/this, tti, . . . , u„]. The 
syntactic restrictions of rule MI also apply to this rule MI’. 
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Next we apply the transformational approach to dynamic binding (in the 
context of inheritance and sub-typing as defined in Java [12]). In general, dy- 
namic binding destroys the static connection between a method call and the 
implementation that is bound to the call. This implies that every implementa- 
tion that might possibly be bound to a call must satisfy the specification of the 
call. That is the most significant change that has to be made to the rule for 
reasoning about methods calls. In order to obtain such a rule we first add to 
each class its inherited methods. Moreover, in order to avoid name clashes, we 
rename every method of a class C by C.m. We extend the assertion language 
with for every class C a monadic predicate C(e), which holds if and only if the 
run-time type of the object denoted by e is C. 

In the context of dynamic binding of method we then translate every call 
eo.m(ei, . . . , e„) into the (nested) conditional statement: 

if Ci(eo) 

then eo.Ci.m(ei, . . . , e^) 
else if C2(eo) 

then eo.C2.m(ei, . . . , e„) 

if Cfc(eo) 
then eo.Ck-m{ei, 

fi 



fi 

fi 

where {Ci, . . . , C„} are all the subclasses of C\ and Ci the (static) type of the 
expression cq. This translation forms the basis of the existing logical formaliza- 
tions of dynamic binding as described, for example, in [1] and [22]. We refer to 
[20] for the details of a transformation of this translation into a corresponding 
proof rule for the given method call eo.m(ei, . . . , e„). 

Of particular interest is an application of the transformational approach to 
Hoare logics for various object-oriented concurrency models. We are already 
working on a completeness proof of a Hoare logic for a simple extension with 
shared-variable concurrency of our object-oriented language: We assume that 
each class contains a so-called start-method denoted by start. The body of the 
start method is executed by a new thread and the calling thread continues its 
own execution. Like in Java we assume that the start method can be called upon 
an object only once (consequently the number of threads is less than or equal 
to the number of existing objects). A thread is formally defined as a stack of 
temporary configurations of the form (S', 7), where S denotes the statement to 
be executed and 7 specifies the values of the temporary variables in S and the 
identity of the active object (denoted by this). 

The assertions in an annotated program describe the top configurations of the 
existing threads. The verification conditions underlying the Hoare logic presented 
in Section 4 describe the sequential flow of control of a thread. 
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In order to characterize the interference between different threads we assume 
that each method has a formal parameter thread which is used to identify the 
executing thread. Every method invocation not involving the start method is 
assumed to be of the form 

eo.m(thread, Cl, . . . , e„). 

That is, we pass the identity of the thread to which the caller belongs to the 
callee. On the other hand, the invocation of a start method is assumed to be of 
the form 

eo.start(eo,ei,...,e„), 

because this invocation starts a new thread originating from the callee denoted 
by eo- 

We can now generalize the interference freedom test introduced in [19] to 
threads as follows. Let P be the precondition of an assignment y := e and 
P' be the precondition of a statement S. We define P' to be invariant over 
the execution of the assignment j/ := e by a different thread if the following 
verification condition holds: 

(P A P” A thread yf thread') ^ P"[e/y], 

where P” is obtained from P' by replacing every temporary variable u by a fresh 
u' and this by this', in order to avoid name clashes between the temporary 
variables and the keyword this in P and P' . Note that thread is assumed to be 
a temporary variable too and is therefore also renamed by thread'. 

This simple extension of our Hoare logic for shared variable concurrency 
will form the basis of an application of the transformational approach to the 
concurrency model of Java involving threads and coordination via reentrant 
synchronization monitors (as described in [2]). 



7 Conclusions 

In recent years, many formal analysis techniques for object-oriented program- 
ming languages have been proposed. The large amount of interest can be ex- 
plained by the wide-spread use of object-oriented languages. However, the for- 
mal justification of many existing Hoare logics for object-oriented programming 
languages is still under investigation. Notably the problem of completeness until 
now defied clear solutions. For example, the logic of object-oriented programs as 
given by Abadi and Leino was not complete [1]. They suspect that their use of 
a ’’global store” model is the source of the incompleteness. 

Von Oheimb showed that his logic for reasoning about a substantial subset 
of Java is (relatively) complete [24]. However, he uses the logic of Isabelle/HOL 
(higher order logic) as specification language. This trivializes the matter of ex- 
pressiveness of the intermediate assertions. Therefore their result does not auto- 
matically carry over to assertion languages that are closer to the programming 
language. This point is further discussed in [17]. 
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Future work concerns first of all the further development of the transforma- 
tional approach to Hoare logics of object-oriented programming. Of particular 
interest is an application of the transformational approach to Hoare logics for 
various object-oriented concurrency models. 

Another interesting line of research concerns the systematic development of 
compositional Hoare logics for object-oriented programs. Note that the Hoare 
logic presented in this paper is compositional only with respect to the flow of 
control structures. However, it is not compositional in the sense of class-based. 
Also our Hoare logic does not provide any formalization of the basic concept of 
an object as an unit of data-encapsulation. We think that such a logic requires 
a formalization of the external observable behavior of an object in terms of 
its traces of events which indicate the sending and reception of messages (as 
described for example in [15]). It is worthwhile to observe that such a notion 
of external observable behavior (which abstracts from the internal state space 
of an object) in fact involves a concurrency view even if the object-oriented 
programming language is purely sequential. 

Finally, we remark that most existing logics for object-oriented programs deal 
with closed programs. Currently we are also investigating trace semantics as a 
possible semantic basis of Hoare logics for open object-oriented programs. 
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Abstract. Behavioural specification based on hidden (sorted) algebra 
constitutes one of the most promising recently developed formal specifi- 
cation and verification paradigms for system development. 

Here we formally introduce a novel concept of behavioural object 
within the hidden algebra framework. We formally define several object 
composition operators on behavioural objects corresponding to the hi- 
erarchical object composition methodology introduced by CafeOBJ. We 
study their basic semantical properties and show that our most gen- 
eral form of behavioural object composition with synchronisation has 
final semantics and a composability property of behavioural equivalence 
supporting a high reusability of verifications. We also show the commu- 
tativity and the associativity of parallel compositions without synchro- 
nisation. 



1 Introduction 

The current Internet /Intranet technologies have led to an explosive increase in 
demand for the construction of reliable distributed systems. Among the new 
technologies proposed for meeting this new technological challenge, component- 
based software engineering is one of the most promising. If we have an adequate 
set of components and a good design pattern, a system development process 
may become easier and the quality of the product may be greatly improved. 
However such development process raises some serious problems. How can we 
get an adequate set of components or how can we know the components we get 
are adequate for our systems? 

A good solution seems to be given by formal specifications supporting the 
following characteristics: 

— can specify the interface of components, 

— can specify the behaviour of components, 

— supports a precise semantics of composition, and 

— be executable or have tools supporting testing and verification. 

Here we adopt the behavioural algebraic specification framework [1, 2, 3, 4]. 
Due to its simple logical foundations and to its efficient specification and verifi- 
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cation methodologies, behavioural algebraic specification provides a good frame- 
work for such formal specifications. Informally, behavioural algebraic specifica- 
tion describe both data types and states of abstract machines by axioms based 
on strict equality, in the case of the data types, and behavioural equality (i.e. 
equality under ‘observations’ to data), in the case of the states of abstract ma- 
chines. Implementations of behavioural specifications are formalised as (many 
sorted) ‘hidden’ algebras interpreting two kinds of sorts as sets, one kind for the 
data types, another kind for the states of the abstract machines, and interpreting 
operations as functions. The operations which determine the behavioural equiv- 
alence between states are specified as special ‘behavioural’ operations. Such a 
‘hidden’ algebra is a model of a specification when all sentences (axioms) of the 
specification are valid for that algebra. 

The work around the CafeOBJ algebraic specification language [5, 6] has 
proposed a hierarchical object composition methodology (see [5, 7, 8]) based 
on behavioural specification. The behavioural specification paradigm is reflected 
rather directly in the definition of CafeOBJ, this being maybe the most distinctive 
feature of this language among other modern algebraic specification languages 
such as CASL [9] or Maude [10]. 

Here we formally define the novel concept of behavioural object within the 
hidden algebra framework, which is the logic of CafeOBJ behavioural specifi- 
cation. Informally, a behavioural object is just a special kind of behavioural 
specification which emphasises a special ‘hidden’ sort for the space of the states 
of the object and special operations for modelling method invocations and at- 
tributes. One of the most important novel related concepts introduced is that of 
equivalence between behavioural objects, which plays an important role in the 
study of the semantical properties of hierarchical object composition. 

This concept is the basis for a precise definition of several types of compo- 
sition operators on behavioural objects, such as parallel composition (without 
synchronisation), dynamic composition (in which component objects gets cre- 
ated and deleted dynamically), and composition with synchronisation generalis- 
ing both the former operators. Informally, these composition operators are based 
on specifications of projections from the state space of the compound object to 
the state spaces of the components. Our definitions give mathematical founda- 
tions for the corresponding methodological definitions of object composition in 
[5, 11, 8]. Our composition operators support hierarchical composition processes 
in the sense that the result of a composition is still a behavioural object which 
can be therefore used in another composition. 

Our framework permits a clear formulation of semantical properties of the 
composition operators, such as associativity and commutativity, and final 
semantics (i.e. the existence of final composition models). We show that the 
basic parallel composition operator is commutative and associative (modulo ob- 
ject equivalence). For the general composition with synchronisation operator we 
prove a compositionality result for the behavioural equivalence relation, result 
which constitute the foundation for automation of the verification process at the 
level of a compound object (see [5, 11, 8]), and the existence of final semantics. 
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The paper is structured as follows. The first section recalls briefly the basic 
mathematical notions necessary for this work. We present first general algebra 
notions, and then we give a very brief overview of hidden algebra. At the end 
of this section we define the concept of behavioural object. The next section 
introduces briefly the CafeOBJ notation for behavioural objects, which will be 
used for the examples, and which is illustrated with two simple examples. The 
main section of the paper is dedicated to the composition operators and contains 
their mathematical definitions together with their main semantic properties. All 
composition operators are illustrated with examples. The final section develops 
an example showing how the compositionality of behavioural equivalence result 
for compositions with synchronisation can be applied for reusing verifications 
within the framework of the CafeOBJ system. 

Here we only give the statements of the mathematical results and omit their 
proofs. These will appear in an extended full version of the paper. 
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2 The Logic of Behavioural Specification 

The semantics of behavioural specification is based on hidden algebra [2, 4, 
3] which is a refinement of general many-sorted algebra. Although the hidden 
algebra formalism accommodates well (and even gets more power from) the 
order-sorted approach (see [12]), for reasons of simplicity of presentation, we 
develop all formal definition and results in a many-sorted framework. 

2.1 General Algebra 

We review here the basic general algebra concepts, notations, and terminology, 
which constitute now the folklore of algebraic specification. 

Given a sort set S, an S-indexed (or sorted) set A is a family of sets 

indexed by the elements of S. In this context, a G A means that a G Ag for some 
s € S. Similarly, AC B means that Ag C Bg for each s G S, and an S-indexed (or 
sorted) function f : A ^ B is a, family {/g : Ag ^ Bg}g^s- Also, we let S* denote 
the set of all finite sequences of elements from S, with [] the empty sequence. 
Given an S'-indexed set A and w = si...s„ G S*, we let = Ag^ x • • • x Ag^; in 
particular, we let Ag = {*}, some one point set. Also, for an A-sorted function 
/ : A — > H, we let /u, : A^ B^ denote the function product mapping a tuple 
of elements (oi, . . . ,a„) to the tuple (/gi(ai), . . . , /s„(a„)). 

A (n S-sorted) signature (S,F) is an S* x 5-indexed set F = {Jfu,^g | w G 
5*, s G S'} of operation symbols. Note that this definition permits overload- 
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ing, in that the sets F^j^s need not be disjoint. Call a € (sometimes 

denoted simply F^g) a constant symbol of sort s. A signature morphism (p from 
a signature (S,F) to a signature {S\F') is a pair consisting of a 

map : S' ^ 5" of sorts and of a map : F ^ F' on operation symbols 
such that C where ((/s’*”*)*: S* S'* is the 

extension of to strings. 

A {S, F)-algebra A consists of an S-indexed set A and a function A^ : ^ 

As for each cr G F^j^s] the set Ag is called the carrier of A of sort s. If cr G F^s 
then Act determines a point in Ag which may also be denoted Ao-. An {S,F)~ 
homomorphism from one (S, J^)-algebra A to another B is an S-indexed function 
h: A ^ B such that hg{Acr{a)) = Ba{hw{a)) for each a G F^j^s and a G A^. 
A (S, A)-homomorphism h: A ^ B is a, {S, F)-isomorphism if and only if 
each function hg : ^ Bg is bijective (i.e., one-to-one and onto, in an older 

terminology). The category (class) of algebras of a signature (S,F) is denoted 
Alg{S,F). 

A F- congruence on a (S', T')-algebra A is an S-sorted family of relations, =g on 
Ag, each of which is an equivalence relation, and which also satisfy the congruence 
property, that given any cr G and any a G A^,, then Ao-(a) =« Aa{a') 

whenever a =w a'.^ 

Given a signature morphism Lp\ (S,F) {S',F') and a (S', T'')-algebra A', 

we can define the reduct of A' to {S,F), denoted A'f,^, or simply A'|'( 5 _^) when 
(f is an inclusion of signatures, to have carriers for s G S, and to have 

operations {A'\,^)^ = A^^^^ for a G F. Then A' is called an expansion of A 
along ip. Reducts can also be easily extended to algebra homomorphisms. 

For any signature (S,F) and (S, A)-algebra A, let (S,Fa) be the elementary 
extension of (S, F) via A which adds the elements of A as new constants, i.e. 
{Fa)^s = F^g U Ag and {Fa)w^s = F,^^g when w is not empty. Let Aa 
denote the expansion of A to (S, Fa) interpreting each element of A by itself, 
i.e. (A^)a = a for each a G A. 

Any F-term t = a{ti . . .t„), where a G F^^g is an operation symbol and 
ti, . . . ,t„ are F-(sub)terms corresponding to the arity w, gets interpreted as an 
element At G Ag in a (S, F)-algebra A by At = A,j{At^ ...At„). When each 
element a of A can be denoted as a = Af for some term t, then we call A a 
reachable algebra. 

For any set X of new constants, called variables, the {F U A)-terms can be 
regarded as F-derived operations by defining the arity ar(t) by the following 
procedure: 

- consider the set varff) C A of all variables occurring within t, 

~ transform var(t) into a string by fixing an arbitrary order on this set, and 
~ finally, replace the variables in the string previously obtained by their sorts. 

Any A-derived operation t with arity w and sort s determines a function 
At'. Ayj Ag such that for each string a of elements corresponding to ar{t). 



^ Meaning ai a' for i = 1, ...,n, where w = si . . . s„ and a = (oi, . . . ,an)- 
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At{a) is the evaluation of t in the expansion of A to U X which interprets the 
variables of X be the corresponding elements of a. 

A F- context c[z] is any f-term c with a marked variable z occurring only 
once in c. 

Given a signature (S,F), the set of {S,F)~ sentences is the least set of sen- 
tences containing the (quantifier-free) equations and which is closed under log- 
ical connectives and quantification. An equation is an equality t = t' between 
F-terms t and t' . For pi and p 2 any (A, F)-sentences, let p\/\p 2 be their conjunc- 
tion which is also a (S', F)-sentence. Other logical connectives are the disjunction, 
implication, negation, etc. For any set X of variables for a signature (S, F), then 
(VA)p is a (S, F)-sentence for each (S, F U A)-sentence p. Similar definition can 
be applied to the existential quantification. 

Given an algebraic signature morphism p: (S,F) (S',F'), each (S, F)- 

sentence p can be translated to a (S', F')-sentence p' , denoted (f{p), by replacing 
any symbol of (S, F) fro p by its corresponding symbol from (S',F') given by 

The satisfaction between algebras and sentences is the Tarskian satisfaction 
defined inductively on the structure of sentences. Given a fixed arbitrary signa- 
ture (S, F) and an (S, F) -algebra A, 

— A \= t = t' if At = Af for equations, 

— A \= Pi p 2 if A \= Pi and A \= p 2 and similarly for the other logical 
connectives, and 

— for each (S, F U A)-sentence A ^ (VA)p if A' \= p for each expansion A' of 
A along the signature inclusion (S, F) ^ (S, F U X). 



2.2 Hidden Algebra 

Hidden algebra (abbreviated ffA) is the logical formalism underlying behavioural 
specification. It extends ordinary general algebra with sorts representing ‘states’ 
of objects, or abstract machines, rather than data elements and also introduces 
a new satisfaction between algebras and sentences, called ‘behavioural satisfac- 
tion’. In the literature there are several versions of hidden algebra, with only 
slight technical differences between them [2, 3, 4]. In the following we review the 
basic concepts of hidden algebra. 

A hidden algebraic signature {H, V, F, F^) consists of a set F[ of hidden sorts, 
a set V of ordinary visible sorts, a set F of (FUF)-sorted operation symbols, and 
a distinguished subset F^ C F of behavioural operations. Behavioural operations 
are required to have at least one hidden sort in their arity. An operation symbol 
which has visible arity and sort is called data operation. 

From an object-oriented methodological perspective, the hidden sorts denote 
sets of ‘states of objects’, the visible sorts denote data types, and the operations 
O' G Fw^s can be thought as ‘methods’ whenever w has exactly one hidden sort 



^ In the particular case of quantifications, notice that this changes the sorts of the 
variables. 
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and s is hidden also, and as ‘attributes’ whenever w has exactly one hidden 
sort and s is visible. This object-oriented interpretation of behavioural logic will 
be formally clarified in the section below by the introduction of the concept of 
‘behavioural object’. 

A {H,V, F, F^)- algebra is just an (i? U F) -algebra. A homomorphism of 

hidden algebras h: A ^ F for a signature {H, V, F, F^) is just a, {F[ LI V, F)- 
algebra homomorphism preserving the behavioural equivalence, i.e. such that 

H^a) Q^b- 

Given a {F[,V, F, F^)-algehra A, a hidden congruence ~ on A is just an 
F^’-congruence which is identity on the visible sorts. The largest hidden F- 
congruence on A is called behavioural equivalence. The following is probably 
the most fundamental result in hidden algebra, providing the foundations for 
the so-called ‘coinduction’ proof method. 

Theorem 1. Behavioural equivalence always exists. 

Hence in order to prove by coinduction that two elements are behaviourally 
equivalent it is enough to prove that they are congruent^ for some arbitrarily 
but conveniently chosen hidden congruence. 

An operation symbol a is coherent for an algebra A when it preserves the 
behavioural equivalence, i.e. Ag.(a) Ag.(a') whenever a a' (possibly 
component- wise) . 

A hidden algebra signature morphism ip: {F[,V, F, F^) {FF ,V' , F' , F'^) is 

a signature morphism {H LV,F)^ {FI' U V , F') such that 

- p{V) C V' and if{H) C H' , 

- ip{F'°) = F''^ and p-^{F''^) C F'°, 

These conditions say that hidden sorted signature morphisms preserve vis- 
ibility and invisibility for both sorts and operations, and the object-oriented 
intuition behind the inclusion F'^ C (p{F^) is the encapsulation of classes (in 
the sense that no new ‘methods’ or ‘attributes’ can be defined on an imported 
class)^. However, this last inclusion condition applies only to the case when sig- 
nature morphisms are used as module imports (the so-called horizontal signature 
morphisms); when they model specification refinement this condition might be 
dropped (this case is called vertical signature morphism) . 

Algebra reducts along hidden algebra signature morphisms are instances of 
the ordinary general algebra reducts along algebraic signature morphisms. 

Given a hidden algebraic signature (iJ, V, F, F^), a behavioural equation t ^ t' 
consists of a pair of F-terms of the same sort. An (iJ, V, F, F*’)-algebra A satisfies 
it, i.e. A 1= t ~ when At An . 

Full first order behavioural sentences are constructed from strict and be- 
havioural equations by iteration of logical connectives and first order quantifica- 
tion in a way similar to the case of ordinary general algebra. 



® In a hidden congruence relation. 

^ For the model theoretic relevance of this condition see [1]. 
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A behavioural presentation {S,E) consists of a hidden algebraic signature S 
and a set E of A-sentences. A presentation morphism p: {E,E) (E',E') is 

just a signature morphism ip: E ^ E' such that E' |= (p{E).^ 

An operation symbol a is eoherent with respect to a presentation {E, E) 
when it is coherent in each algebra of the presentation. 

2.3 Behavioural Objects 

The definition below introduces the novel concept of ‘behavioural object’ as a 
stylised way of structuring a hidden algebra based behavioural specification, 
so that it models the behaviour of objects from object-oriented programming. 
Notice that our hidden algebra approach to object semantics is more general than 
corresponding co-algebraic approaches (such as [13], for example) because of the 
much greater specification power of hidden algebras, which is due to the smooth 
integration between state and data types, and to the possibility of operations 
with multiple hidden sorts in the arity. 

Definition 1. A behavioural object B is pair consisting of a behavioural pre- 
sentation {{Hb,Vb, Eg, Eb), Eb) and a hidden sort hB G Hb such that each be- 
havioural operation in Eg is monadic, i.e. it has only one hidden sort in its arity. 

The hidden sort hB denotes the states of B. The visible sorted behavioural 
operations on hB are called B-observations and the hB-sorted behavioural oper- 
ations on hB are called B-actions. The hB-sorted operations with visible sorted 
arity are called constant states.® 

For the sake of simplifying notation, without loss of generality, we may as- 
sume that the arity of any behavioural operation of an object is of the form hw 
with h hidden sort. 

A derived behavioural operation is any derived operation of the form a{T,t) 
such that a is a behavioural operation or coherent with respect to the behavioural 
object and t is a variable or a derived behavioural operation. Notice that ordinary 
behavioural operations can be regarded as special cases of derived behavioural op- 
erations. 

The following expresses the fact that any object is essentially defined by its 
state space, its actions, and the behavioural equivalence between the states. 

Definition 2. For any behavioural object B, a B-algebra is just an algebra for 
the signature of B satisfying the sentences Eb of the presentation of the object 
B. The category of B- algebras is denoted by Alg{B). 

Two B-algebras A and A' are equivalent, denoted A = A' , when 

— Ahs = A'f,^^ and ^a=^A' (on the sort Hb), and 

— Acr = A!^ for each B-action a 

Definition 3. Two behavioural objects B and B' are equivalent, denoted B = 
B' , when there exists a pair of functors <F : Mg{B) Mg{B') and F : Mg{B') 



® Any hidden algebra satisfying E' satisfies p>{E) too. 

® They should be considered as parameterised by the data arguments of the arity. 
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Alg{B) such that A = <P(^(A)) for each B-algebra A and A' = <P{'B{A’)) for each 
B' -algebra A! . 

Therefore behavioural objects are equivalent when they admit the same ‘im- 
plementations’. Notice that this defines indeed an equivalence relation and that 
isomorphic objects are equivalent. 

We may also extend the concept of reduct of algebras from behavioural pre- 
sentation morphisms to behavioural object morphisms. 



3 The CafeOBJ Notation 

CafeOBJ (whose definition is given by [5] and logical foundations in [6]) is a 
modern successor of the OBJ [14] language incorporating several new major 
developments in algebraic specification theory and practice. CafeOBJ is aimed 
both to researchers and (industry) practitioners. 

Behavioural specification might be the most distinctive feature of CafeOBJ 
within the broad family of algebraic specification languages. This is incorporated 
into the design of the language in a rather direct way. 

CafeOBJ methodologies introduce a graphical notation extending the classical 
ADJ-diagram notation for data types to behavioural objects in which 

Gl. Sorts are represented by ellipsoidal disks with visible (data) sorts represented 
in white and hidden (state) sorts represented in grey, and 
G2. Operations are represented by multi-source arrows with the monadic part 
from the hidden sort thickened in case of actions and observations. 

As example let us consider the signature of a bank account behavioural object 
ACCOUNT which uses a pre-defined data type of natural numbers (represented 
in this figure by the sort Nat and in the equations below by the operation --I- -): 
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and with the following universally quantified equations 
eq balance(init-account) — 0 . 
eq balance(deposit(A, N)) = balance(A) + N . 

ceq balance(withdraw(A, N)) = balance(A) - N if A/ <= balance(A) . 
ceq balance(withdraw(A, N)) = balance(A) if A/ > balance(A) . 

Notice that the last two equations are conditional, i.e. they are universally 
quantified implications between a condition and an equation. In this example the 
conditions are just binary relations, however they can be regarded as equations 
between Boolean- valued terms. More generally, a condition of a conditional equa- 
tion can be thought as quantifier-free formula formed from equations by iterative 
applications of conjunction, disjunction, and negation. 

We can also easily prove that in any ACCOUNT-algebra A, 

a a' if and only if Abalance(a) = Abalance(a') 

A more sophisticated example is provided by a behavioural object of sets 
BSET in which the sets of elements appear as states of this object. The signature 
of BSET is given by the diagram below and which uses a sort Elt for elements of 
sets and a pre-defined Boolean type (represented in the figure by the sort Bool 
and in the equations below by several standard Boolean operations): 




Notice that there is only one behavioural operation, the membership obser- 
vation in, the operations {_} standing for regarding elements as singleton sets, 
U standing for union of sets, and - standing for the difference between sets not 
being specified as behavioural. The equations are as follows: 

eq E in empty = false . 

eq E in { E’ } = (E == E') . 

eq £ in (5 U S’) = (E in S) or (E in S’) . 

eq £ in (S - S’) = (E in S) and not(E in S’) . 



Behavioural Specification for Hierarchical Object Composition 



143 



Notice that the behavioural equivalence is given by the element membership 
observation only and that in all algebras the interpretation of the other opera- 
tions preserve the behavioural equivalence, hence these operations are coherent 
with respect to this specification. 

The reader is invited to compare the level of complexity of the behavioural 
specification of sets with that of the classical data type specification based on ini- 
tial semantics. This gap in favour the behavioural style is even bigger in the case 
of proofs, such as distributivity of the set difference over the set union _U_. 



4 Hierarchical Object Composition 

4.1 General Considerations 

Our methodology for behavioural object composition has been defined informally 
within the framework of the CafeOBJ language [5, 7]. Here by formally defining 
composition operations on behavioural objects (see Definition 1), we can export 
the CafeOBJ behavioural object composition methodology to any specification 
and verification language implementing a form of behavioural logic close to our 
hidden algebra formalism. 

Our behavioural object composition methodology is hierarchical in the sense 
that the composition of behavioural objects yields another behavioural object 
in the sense of Definition 1, which can also be used for another composition. 
Hierarchical behavioural object composition can be represented in UML notation 
as follows: 




In the above UML figure, B is composed of D and E, A of B and C, and 
non-compound objects (i.e., objects with no components) are called base level 
objects. A composition is represented in UML by lines tipped by diamonds, and 
if necessary, qualified by the numbers of components (1 for one and * for many). 
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Projection operations from the hidden sort of the states of the compound 
object to the hidden sorts of the states of the component objects constitute the 
main technical concept underlying the CafeOBJ composition method; projection 
operations are related to the lines of UML figures. Projection operations are 
subject to several mathematical conditions which will be formally clarified later. 
These are in essence as follows: 

1. all actions of the compound object are related via projection operations to 
actions in each of the components, 

2. each observation of the compound object is related via the projection oper- 
ations to an observation of some component, and 

3. each constant state of the compound object is projected to a constant state 
on each component. 

In the compound objects we only define communication between the compo- 
nents; this means that the only equations at the level of the specification of the 
compound objects are the ones relating the actions and observations of the com- 
pound objects to those of the components as described above. All the equations 
for the projection operations are strict rather than behavioural, however we may 
also define them behaviourally without affecting our semantics and methodology. 

The components of a compound object are connected in parallel if there is no 
synchronisation between them. In order to define the concept of synchronisation, 
we have to introduce the following concept. 

Definition 4. Two actions of a compound object are in the same action group 
when they change the state of the same component object via a projection oper- 
ation. 

Synchronisation appears when: 

— there exists an overlapping between some action groups, in the sense that 
some action of the compound object is projected to at least two components 
affecting their state changing simultaneously, or 

— the projected state of the compound object (via a projection operation) 
depends on the state of a different (from the object corresponding to the 
projection operation) component. 

The first case is sometimes called broadcasting and the second case is some- 
times called client-server computing. In the unsynchronised case, we have full 
concurrency between all the components, which means that all the actions of the 
compound object can be applied concurrently, therefore the components can be 
implemented as distributed processes or concurrent processes with multi-thread 
which are based on asynchronous communications. 

In the case of synchronised compositions, the equations for the projection 
operations are conditional rather than unconditional. Informally, their conditions 
are subject to the following conditions: 

~ each condition is a quantifier-free formula formed from equations by itera- 
tion of negation, conjunction, and disjunction, the terms in the equations 
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being compositions between a projection and a composition chain of ac- 
tions/observations (at the level of the component) or terms in the data sig- 
nature, and 

~ the disjunction of all the conditions corresponding to a given left hand side 
(of equations regarded as a rewrite rule) is true. 



4.2 Parallel Composition 

Parallel composition (i.e. without synchronisation) is the most fundamental form 
of behavioural object composition. As example we consider a very simple bank 
account system which consists of a fixed numbers of individual accounts, lets 
actually consider the case of just two accounts. The specification of an account 
can be obtained just by renaming the specification ACCOUNT of a counter object 
with integers. In CafeOBJ notation this is achieved as follows 

mod* ACCOUNTl { protecting(ACCOUNT *{ hsort Account -> Accountl, 

op init-account -> init-accountl })} 

mod* ACCOUNT2 { protecting(ACCOUNT *{ hsort Account -> Account2, 

op init-account -> init-account2 })} 

We then compose these two account objects as in the following double fig- 
ure containing both the UML and the CafeOBJ graphical^ representation of this 
composition, where depositl and withdrawl are the actions for the first account, 
balancel is the observation for the first account, accountl is the projection oper- 
ation for the first account, and deposit2, withdraw2, balance2, and account2 are 
the corresponding actions, observation, and projection operation for the second 
account : 




^ The CafeOBJ graphical representation corresponds to the module defining this object 
composition rather than to the “flattened” specification, hence the operations of the 
components are not included in the figure. 
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The equations for this parallel composition are as follows: 

eq balancel(AS) = balance(accountl(AS)) . 
eq balance2(AS) = balance(account2(AS)) . 
eq accountl(depositl(AS, N)) = deposit(accountl(AS), N) . 
eq accountl(deposit2(AS, N)) = accountl(AS) . 
eq accountl(withdrawl(AS, N)) = withdraw(accountl(AS), N) . 
eq accountl(withdraw2(AS, N)) = accountl(AS) . 
eq account2(init-account-sys) = init-account2 . 
eq account2(depositl(AS, N)) = account2(AS) . 
eq account2(deposit2(AS, N)) = deposit(account2(AS), N) . 
eq account2(withdrawl(AS, N)) = account2(AS) . 
eq account2(withdraw2(AS, N)) = withdraw(account2(AS), N) . 

Notice that besides the first two equations relating the observations on the 
compound object to those on the components, the other equations relate the ac- 
tions of the account system to the actions of the components. Remark that the 
actions corresponding to one component do not change the state of the second 
component (via the projection operation), hence this composition is unsynchro- 
nised. In fact these equations expressing the concurrency of composition need 
not be specified by the user, in their absence they may be generated internally 
by the system, thus reducing the specification of the composition to the essential 
information which should be provided by the user. 

The following provides a formal definition for parallel composition of be- 
havioural objects. Another parallel composition concept as operators on speci- 
fications has been defined in [1] within a more restricted hidden algebra frame- 
work. 

Definition 5. A behavioural object B is a parallel composition of behavioural 
objects Bi and B 2 when 

— Hb = Hb^ W Hb2 W 

- Vb = Vbi U Vb2 , 

— (Fb)w^s = (Fbi)w^s U {Fb 2 )w^s when all sorts in ws are visible, 

- (Fb) w — *s — I^Fb^Iw — * s when ws contains hidden sorts from only, for 

“ (Fb)w^s = 0 when ws contains hidden sorts from both Hi and H 2 only, 

- {FB)hB^hB^ = {T^i} for i € {1,2}, 

^Fb^Hbw — *Hb {o^i I O' G (^FB^^^hB^w — Bi~action, i G (1,2}} 

— the behavioural operations F}j of Fb are those from Fg^ and Fg^, tti, 7T2, 
and the actions and the observations on Hb, 

~ Eb = Ebi U Eb^ U 

{(V{a;} U W)7Ti{ai{x, W)) = cr(7Ti(x), W) \ a Bi-action, z G {1, 2}} 
\j{iy{x}\JW)TTj{ai{x,W))=TTj{x)\a Bi-action {z,j} = {l,2}} 
U{e(cr)|cr B-observation} U[j^ B -state constant 



By W we denote the disjoint union. 
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where e{a) is a derived observational definition of a and E{c) is a derived 
constant set of definitions for c. 

For each B-observation a we say that an equation (V{x} U W)a{x, W) = 
Ta-{TTi{x), W) is a derived observational definition of a when i G {1, 2} and where 
Ter is a (possibly derived) Bi-observation. 

For each B-state constant c we say that E{c) = {Ti{c) = Ci\i G {1,2}} for 
some Ci is a Bi-state constant is a derived constant set of definitions for c. 

Let us denote by Bi\\B 2 the class of behavioural objects B which are parallel 
compositions of behavioural objects B\ and i? 2 - 

This definition can be easily extended to any finite number of objects. 

The following shows that in the case of parallel composition without synchro- 
nisation the behavioural equivalence on the compound object is compositional 
with respect to the behavioural equivalences of its components. 

Proposition 1. For any behavioural objects B\ and B 2 , for each parallel com- 
position B G B 1 WB 2 , we have that 

a^A a,' if and only if Arr^{a) ^Ai ATr^{a') and Arr.^{a) ^a 2 ArT2 (a ) 

for each B -algebra A, elements a, a' G Ah,;, and where Ai = A\si for each 
ze{i,2}. 

The following shows that parallel composition is unique up to object equiv- 
alence. 

Proposition 2. Let Bi and B 2 be behavioural objects. Then all B,B' G 
have isomorphic classes of algebras. 



Corollary 1. For all behavioural objects B\ and B 2 , all B,B' G B 1 WB 2 are 
equivalent objects, i.e. B = B' . 

Notice that we cannot expect two parallel compositions to be isomorphic (as 
presentations) because observations on the compound objects can be defined 
differently, hence their signatures need not be isomorphic. However, modulo the 
definition of the observations on the compound objects, parallel composition 
without synchronisation is uniquely determined. This permits a high degree of 
automation of the specification of parallel composition. 

Definition 6. Let B G B 1 WB 2 and let Ai be algebras of Bi for i G {1,2} such 
that they are consistent on the common data part.^ A H-algebra A expands Ai 



® Bi !(v,Fi/) = B2\(v,Fv) where V = Vbi n Vb 2 and Fy is the set of all data operation 
symbols in Fbi Pi Fbj. 




148 



R. Diaconescu 



and A 2 when A\Bi = Ai for each i G {1,2}. A B-algebra homomorphism 
/ : A ^ A' expands Ai and A 2 when f\Bi = ^Ai for each i € (1, 2}. 

The following shows that parallel composition admits final semantics: 

Theorem 2. Let B G i?i|ji ?2 and let Ai be algebras of Bi for i G {1,2} such 
that they are consistent on the common data part. Then there exists a B-algebra 
A expanding Ai and A 2 such that for any other B-algebra A' expanding Ai and 
A 2 there exists an unique B-algebra homomorphism A' ^ A expanding A\ and 

A2- 



Parallel composition has several expected semantic properties such as asso- 
ciativity and commutativity. 

Theorem 3. For all behavioural objects B\ and B 2 and B^ 

1 . Bi\\B 2 = B 2 WB 1 , and 

^( 12)3 = ^1(23) for all i?(i2)3 G B 12 WB 3 and all i?i(23) G .B 1 II.B 23 , where Bij 
is any composition in Bi\\Bj. 




4.3 Dynamic Composition 

Let us extend the previous bank account system example to support an arbi- 
trary number of accounts as a ‘dynamic’ object ACCOUNT-SYS. The accounts 
are created or deleted dynamically, so we call such architecture pattern dy- 
namic composition and we call the objects composed dynamically as dynamic 
objects. 

The actions add-account and del-account maintain the user accounts, add- 
account creates accounts while del-account deletes the accounts; both of them 
are parameterised by the user identifiers DID (represented by the sort Did). Each 
of deposit and withdraw are also parameterised by the user identifiers. Most 
notably, the projection operation for ACCOUNT is also parameterised by UID. 
The structure of the new bank account system can be represented in UML and 
CafeOBJ graphical notation as follows: 
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AccountSys 



depositl 

deposit2 

withdrawl 

withdraw2 



* 



1 



Account 



deposit 

withdraw 




Finally, the equations relate the actions of ACCOUNT-SYS to those of AC- 
COUNT via the projection operation only when they correspond to the specified 
user account. Here is the essential part of the CafeOBJ equations for the dynamic 
system of accounts specification: 

ceq account(add-account(AS, U'), U) = init-account if U == U' . 

ceq account(add-account(AS, U'), U) = account(AS, U) if U =/= U' . 

ceq account(del-account(AS, U'), U) = no-account if U == U' . 

ceq account(del-account(AS, U'), U) = account(AS, U) if U =/= U' . 

ceq account(deposit(AS, U', N), U) = deposit(account(AS, U), N) \f U == U' . 

ceq account(deposit(AS, U’, N), U) = account(AS, U) if U =/= U' . 

ceq account(withdraw(AS, U’, N), U) = withdraw(account(AS, U), N) if U == U’ . 

ceq account(withdraw(AS, U’, N), U) = account(AS, U) if (i =/= U' . 

Notice that dynamic object compositions generalise the ordinary projections 
to projections which are parameterised by the data types (Uld) and also that 
dynamic compound objects might add new actions {add-account and del-account) 
which do not correspond to actions of the components. 

4.4 Synchronised Parallel Composition 

In this section we define the most general form of object composition of our 
approach. This supports dynamic compositions and synchronisation both in the 
broadcasting and client-server computing forms. 

As example let us add to the parallel system of two accounts specified above 
a transfer action transfer from the first account to the second one. This is of 
course parameterised by the amount of money to be transfered. The signature 
of this composition looks now as follows: 



150 



R. Diaconescu 




and the equations for the transfer are as follows: 

eq accountl(transfer(AS, N)) = withdraw(accountl(AS), N) . 

ceq account2(transfer(AS, N)) — account2(AS) if A/ > balancel(AS) . 

ceq account2(transfer(AS, N)) = deposit(account2(AS), N) if N <= balancel(AS) 

This example of transfer between accounts, although very simple, contains 
both the broadcasting and the client-server computing cases. Broadcasting ap- 
pears because the transfer changes the states of both account components. Client- 
server computing appears because transfer is related to deposit of ACCOUNT2 
and using information of ACCOUNTl. 

The following is the formal definition of composition with synchronisation 
generalising the Definition 5 of parallel composition without synchronisation. 

Definition 7. A behavioural object B is a synchronised composition of be- 
havioural objects Bi and B 2 when 

— Hb = Hb^ W Hb2 W {hB}, 

~ Vb D Vbi U Vb2 , 

— (Fb)w^s 2 (Fbi)w^s U {Fb 2 )w^s when all sorts in ws are visible, 

— {Fb)w^s = (FBi)w^s when ws contains hidden sorts from FlBi only, for 

~ (Fb)w^s = 0 when ws contains hidden sorts from both FIb^ and Hb 2 only, 

— for each i € {1, 2}, there exists an unique Wi string of visible sorts, such that 

(FB)hBWi^hB ^0^ empty, and it contains only one operation symbol iTi, 
{FB^hBW — >hB — I ^ G ^FB^jiiB^w — *h,B,^ B^-action, i fE {1,2}} 

— the behavioural operations Fl of Fb are those from Fg^ and Fg^, tti, tt 2 , 
and the actions and the observations on hg, 

— Eb = Eb, U Eb2 U U, B -action ^ {e(o') \ a B -observation} 

B -state constant F{F) 
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where is a complete set of derived action definitions for a, e(a) is a derived 
observational definition for a, and E{c) is a derived constant set of definitions 
for c. 

For any B-action a, 

{{y{x}\JW\JWf)T,fia{x,W),W,) = Tf^^[x,W,W,\ if IH, IH,] | 

rf f. term, i G {1, 2}, fc G {1, . . . , Ui}} is a complete set of derived action defini- 
tions for a when 

1. each rf W, Wi] is a hsi-sorted term of behavioural or coherent Bi-opera- 
tions applied either to TTi{x,Wi) or to a Bi-state constant, and 

2. each f,[x, W, Wi] is a quantifier-free formula formed by iterations of nega- 
tions, conjunctions, and disjunctions, from equations formed by terms which 
are either data signature terms or visible sorted terms of the form cliTjfx, Wj)] 
for c some derived behavioural Bj -operation with Wj C W U Wj and such 
that 

(2.1) the disjunction (V{a;} UWU Wi) | /c G {1, . . . ,Ui}} is true for 

each z G {1, 2}, 

(2.2) for a given i, the conditions ^ are disjoint, i.e. (V{x} UWU Wi) 
Cl. I,. AC),. is false whenever k k! , 

The meaning of condition (2.1) is that of completeness in the sense that all 
cases are covered, while the meaning of (2.2) is that of non- ambiguity in the sense 
that each case falls exactly within the scope of only one conditional equation. 

Let us denote by Bi ® B 2 the class of behavioural objects B which are syn- 
chronised compositions of behavioural objects B\ and B 2 . 

The above definition for composition with synchronisation can be extended 
easily to the case of any finite number of objects. 

Notice that the example of dynamic account system presented above is a 
special case of Definition 7. 

The following result showing that the behavioural equivalence on the com- 
pound object is compositional with respect to the behavioural equivalences of 
its components extends Proposition 1. 

Theorem 4. For any behavioural objects B\ and B 2 , for each composition with 
synchronisation B ^ B\® B 2 , we have that 

a a' if and only if (VlTi)T^,(a, Wf) Wi) for z G {1, 2} 

for each B -algebra A, elements a, a' G Ahi^, and where Ai = A\si for each 
zG{1,2}. 

Our object composition with synchronisation has final semantics shown by 
the result below generalising Theorem 2: 

Theorem 5. Let B & B\® B 2 and let Ai be algebras of Bi for i G {1,2} such 
that they are consistent on the common data part. Then there exists a B -algebra 
A expanding A\ and A 2 such that for any other B -algebra A' expanding A\ and 
A 2 there exists an unique B-algebra homomorphism A' ^ A expanding A\ and 
A 2 . 
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5 Compositionality of Verifications 

In object-oriented programming, reusability of the source code is important, but 
in object-oriented specification, reusability of the proofs is also very important 
because of the complexity of the verification process. We call this composition- 
ality of verifications of components. Our approach supports compositionality of 
verifications via Theorem 4. 

Let us specify a dynamic bank account system having a user management 
mechanism given by a user database (USER-DB) which enables querying whether 
an user already has an account in the bank account system. The users data base 
is obtained just by reusing (renaming) the behavioural sets object BSET. 

mod* USER-DB { protecting(BSET *{ hsort BSet -> UserDB, hsort Elt -> UId})} 

The following is the UML and CafeOBJ graphical representation of this dy- 
namic bank account system specification: 




and here are the CafeOBJ equations for the projection operation for UserDB: 

eq user-db(add-account(AS, U)) = { U } U user-db(AS)) . 
eq user-db(del-account(AS, U)) = user-db(AS) - { U } . 
eq user-db(transfer(AS, U, U\ N)) — user-db(AS) . 
eq user-db(deposit(AS, U, N)) = user-db(AS) . 
eq user-db(withdraw(AS, U, N)) = user-db(AS) . 

The following is the CafeOBJ code for the equations for the projection oper- 
ation for Account: 

ceq account(add-account(AS, U'), U) = init-account 
(U == U') and not(U in user-db(AS)) . 
ceq account(add-account(AS, U'), U) = account(AS, U) 
if (U =/= U') or (U in user-db(AS)) . 
ceq account(del-account(AS, U'), U) = no-account 
if (U == U') . 

ceq account(del-account(AS, U'), U) = account(AS, U) 
if (U =/= U’) . 

ceq account(transfer(AS, U', U" , N), U) = account(AS, U) 
if (U’ == U") . 



Behavioural Specification for Hierarchical Object Composition 



153 



ceq account(transfer(AS, U’, U", N), U) = account(AS, U) 

if (U’ =/= U") and (W =/= U) and (U" =/= U) . 
ceq account(transfer(AS, U', U" , N), U) = withdraw(account(AS, U), N) 
if (W =/= U”) and (W == U) 
ceq account(transfer(AS, U’, U" , N), U) = account(AS, U) 

if (U’ =/= U”) and (U" == U) and (balance(account(AS, U’)) < N) . 
ceq account(transfer(AS, U', U" , N), U) = deposit(account(AS, U), N) 

d (W =/= U") and (U" == U) and (N <= balance(account(AS, U'))) . 
ceq account(deposit(AS, U', N), U) = deposit(account(AS, U), N) 
if (U == U’) . 

ceq account(deposit(AS, U', N), U) = account(AS, U) 
if (U =/= U’) . 

ceq account(withdraw(AS, U', N), U) = withdraw(account(AS, U), N) 
if (U == U') . 

ceq account(withdraw(AS, U', N), U) = account(AS, U) 
if (U =/= U’) . 

By iterative application of Theorem 4, in the case of a hierarchic object 
composition, the behavioural equivalence for the whole system is just the con- 
junction of the behavioural equivalences of the base level objects, which are 
generally rather simple. 

For example, the behavioural equivalence for the bank account system is a 
conjunction of the behavioural equivalence Account (indexed by the user iden- 
tifiers) and UserDB, and these two are checked automatically by the CafeOBJ 
system. This means that behavioural proofs for the bank account system are 
almost automatic, without having to go through the usual coinduction process. 
Therefore, the behavioural equivalence -R[-]- of AccountSys can be defined by 
the following CafeOBJ code: 

mod BEQ-ACCOUNT-SYSTEM { protecting(ACCOUNT-SYSTEM) 
op -R[-]- '■ AccountSys UId AccountSys -> Bool 
vars ASl AS2 : AccountSys 
var U : UId 

eq ASl R[U] AS2 = account(ASl, U) =b= account(AS2, U) and 
user-db(ASl) =b= user-db(AS2) . } 

Notice the use of the parameterized relation for handling the conjunction 
indexed by the user identifiers, and we use =b= to denote the behavioural equiv- 
alence on the components. We may recall that the definition of =b= for ACCOUNT 
is just equality under the observation balance and that of =b= for USER-DB is just 
equality under arbitrary membership, thus both of them are coded very easily. 

Now, we will prove the true concurrency of deposit operations of two (possibly 
but not necessarily different) users, which can be considered as a safety prop- 
erty for this system of bank accounts and which is formulated as the following 
behavioural commutativity property: 
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deposit{deposit{as, u2, n2),ul, nl) ~ deposit{deposit{as, ul, nl), m2, m2) 

The following CafeOBJ code builds the proof tree containing all possible cases 
formed by orthogonal combinations of atomic cases for the users with respect to 
their membership to the user accounts data base. The basic proof term is TERM. 
The automatic generation of the proof tree (RESULT) is done by a meta-level 
encoding in CafeOBJ by using its rewrite engine for one-directional construction 
of the proof tree (this process uses the rewriting logic feature of CafeOBJ, hence 
the use of transitions (trans) rather than equations). 

mod PROOF-TREE { protecting(BEQ-ACCOUNT-SYSTEM) 
ops nl n2 : -> Nat — arbitrary amounts for deposit 
ops u ul ul' u2 u2' : -> UId — arbitrary user identifiers 
op as : -> AccountSys — arbitrary state of the account system 
eq ul in user-db(as) = true . — first user is in the data base 
eq u2 in user-db(as) = true . — second user is in the data base 
eq ul' in user-db(as) = false . — hrst user is not in the data base 
eq u2' in user-db(as) = false . — second user is not in the data base 
vars U Ul U2 ■\}\6 

op TERM : UId UId UId -> Bool — basic proof term 

trans TERM(U, Ul, U2) => deposit(Ul, nl, deposit(U2, n2, as)) R[U] 

deposit(U2, n2, deposit(Ul, nl, as)) . 

op TERMl : UId UId -> Bool 

trans TERM1(U, Ul) => TERM(U, Ul, u2) and TERM(U, Ul, u2') . 
op TERM2 : UId -> Bool 

trans TERM2(U) => TERM1(U, ul) and TERM1(U, ul') . 
op RESULT : -> Bool — final proof term 

trans RESULT => TERM2(ul) and TERM2(ul') and TERM2(u) . } 

The execution of the proof term RESULT gives true. 

The same problem for withdrawals rather than deposits is a bit more subtle. 
If we run the system for the behavioural commutativity property 

withdraw(withdraw(as, m 2, n2), m 1, nl) ~ withdraw(withdraw(as, ul, nl), m 2, n2) 

in the same manner as for the deposit case, we do not get true because for the 
case when the users are not different, two withdrawals are not necessarily commu- 
tative. This is due to the relation between the amount required for withdrawals 
and the actual balance of the account. However we still get useful information 
consisting of the list of cases which cannot be reduced to true. This shows the 
debugging power of this verification methodology. 

As further exercise the reader is invited to check other behavioural properties 
of the dynamic bank account system with user data base, such as 

transfer(transfer(as, m1, m 2, n), m2, m 3, n) ~ transfer(as, m1, m 3, n) 



6 Conclusions and Future Research 

Based on a novel formalisation of the concept of behavioural object in hid- 
den algebra, we have formally defined several composition operators underlying 
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the object composition methodology of CafeOBJ, including parallel composition 
(without synchronisation), dynamic composition, and a most general form of 
composition with synchronisation. We have showed the associativity and com- 
mutativity of parallel composition (without synchronisation), the existence of 
final semantics and a compositionality result for the behavioural equivalence in 
the most general case of composition with synchronisation. This latter result is 
the basis for making the verification process almost automatic and also leads to 
easy debugging. 

Within this framework we plan to investigate sufficient conditions on synchro- 
nisation allowing final associativity and/or commutativity of the composition 
operator. 

The concepts introduced in this paper can also be used for the definition of 
an object-oriented algebraic specification language supporting hierarchical object 
composition on top of existing algebraic specification languages. For example, 
any specification in such object-oriented extension of CafeOBJ could be compiled 
into a CafeOBJ specification. 
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Abstract. The Unified Modeling Language (UML) favors the construc- 
tion of models composed of several submodels, modeling the system com- 
ponents under development at different levels of abstraction and from 
different viewpoints. Currently, consistency of object-oriented models ex- 
pressed in the UML is not defined in the UML language specification. 
This allows the construction of inconsistent UML models. Defining con- 
sistency of UML models is complicated by the fact that UML models 
are applied differently, depending on the application domain and devel- 
opment process. As a consequence, a form of consistency management 
is required that allows the software engineer to define, establish and 
manage consistency, tailored specifically to the development context. In 
recent years, we have developed a general methodology and tool sup- 
port to overcome this problem. The methodology is based on a thorough 
study of the notion of consistency and has led to a generic definition of 
the notion of consistency. Our methodology itself aims at a step-wise sys- 
tematic construction of a consistency management process, by providing 
a number of activities to be performed by the software engineer. It is 
complemented by a tool called Consistency Workbench which supports 
the software engineer in performing the methodology. In this paper, we 
provide an overview and summary of our approach. 



1 Introduction 

A model-based approach to the development of component-based systems fa- 
vors the construction of models prior to the coding of components. Benefits of 
such an approach are the ability to study properties of the system early in the 
development process on the model level and the idea that components can be 
deployed more easily to different target platforms. 

Currently, the Unified Modeling Language [27] is the de-facto industrial stan- 
dard for object-oriented modeling of components. In the UML a model is 
composed of several submodels for modeling the system at different levels of abstrac- 
tion and from different viewpoints. As the UML language specification does not 
sufficiently define consistency of UML models, inconsistent UML models can be 
constructed. This may lead to a situation where no common implementation con- 
forming to all submodels exists. Further, with the UML being applied in diverse 
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contexts, the ability of defining and checking consistency conditions depending 
on the application domain, development process, and platform is of increasing 
importance. 

Besides well-formedness rules in OCL as part of user-defined UML profiles, 
little support is available for customized specification and checking of consistency 
conditions. This applies both for the definition as well as check of consistency 
conditions. In particular, no support is provided to the developer to specify be- 
havioral consistency conditions, like specific notions of compatibility between 
statecharts and sequence diagrams. The general problem of defining and estab- 
lishing consistency in UML is complicated by a missing formal semantics. 

In [12, 8] we have developed a general methodology for consistency manage- 
ment in UML-based development. Our approach to defining consistency concepts 
is by means of partial translations of models into a formal language (called se- 
mantic domain) that provides a language and tool support to formulate and 
verify consistency conditions. For a given consistency concept, within a con- 
sistency check one or more submodels are translated into a semantic domain 
and the specified consistency conditions are verified. The result may then be 
translated back into a UML notation or simply expressed in a message to the 
modeller. 

Given a development process and application domain, our approach system- 
atically constructs a consistency management process in several activities. First, 
consistency problem types are identified and then formalized in consistency con- 
cepts. The formalization includes the choice of a suitable semantic domain, the 
specification of partial translations and consistency conditions. For each consis- 
tency concept, consistency checks are defined and integrated into the develop- 
ment process. Primary ideas of our approach are to define consistency concepts 
based on the development context, i. e. depending on application domain, devel- 
opment process and platform, and further to abstract from unnecessary details 
of the model not relevant to the consistency condition. 

In order to make our approach applicable in practice, tool support is required 
both for the definition of translations and consistency checks and for their auto- 
mated execution. This has led to the development of the Consistency Workbench, 
a research prototype for demonstrating the feasibility of our approach. 

In this paper, we give an overview and summary of our approach. We first dis- 
cuss the issue of consistency of models made up of different submodels, introduc- 
ing a generic definition of consistency and the notion of consistency management. 
We then present a general methodology for consistency management. Based on 
this methodology, we summarize the tool support we have developed. We finally 
sketch the application of the methodology to an example consistency problem. 
This paper summarizes contributions previously published: The concepts of the 
methodology have first been presented in [12] and then been elaborated in [10] 
and [1 1] . The concepts of the consistency management tool have been published 
in [9]. In [22], the methodology is described in detail, together with an application 
to a simplified development process. 
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2 Concepts of Consistency and Consistency Management 

In this section, we first introduce the main notions of our definition of consistency. 
We then explain the idea of consistency management and briefly discuss related 
approaches. 

2.1 Consistency 

The use of models consisting of different submodels within software development 
has numerous advantages. Different persons may work on different submodels 
simultaneously driving forward the development of the system. Different types 
of submodels allow the separation of different aspects of the system to be built 
such as structural aspects or dynamic behavior of system components. 

However, making use of different submodels also involves drawbacks. In a 
traditional approach, there exists only one model of the system. This model 
can then be transformed during coding into a running software product. In the 
case of a collection of submodels, this is not as easy anymore because one needs 
to describe which submodel is transformed into which part of the code. This 
gives rise to the problem of different parts of the code not working together as 
one wishes leading to a system not functioning. In order not to run into such 
problems, it has to be ensured that different submodels are compatible with each 
other or consistent on the model level. 

Different submodels of a model are usually called consistent if they can be 
integrated into a single model with a well-defined semantics. The required form 
of integration is dependent on the type of models, the modeling process and 
the application domain. One important aspect of consistency is to ensure the 
existence of an implementation conforming to all submodels. If consistency of a 
model is ensured, an implementation of submodels is obtained by implementing 
the integrated model. Otherwise, such an integrated model and implementation 
might not exist. 

Technically, consistency of a model is defined by establishing a set of con- 
sistency conditions. A consistency condition is a predicate that defines whether 
or not a model is consistent with respect to this consistency condition. We can 
distinguish between consistency conditions defined on the syntax and on the se- 
mantics of models, leading to syntactic and semantic consistency conditions. In 
case of defining consistency conditions on the semantics of models, typically also 
a semantic mapping is required. This can be the semantic mapping of the mod- 
eling language definition but can also involve an abstraction of this semantics. 

Different related consistency conditions can be grouped to form a consistency 
concept. Such a consistency concept consists of a set of syntactic and semantic 
consistency conditions and a semantic mapping of each submodel type into a 
common semantic domain if applicable. The definition of a consistency concept 
is illustrated in Figure 1. Mappings of submodel types are called nii in the 
figure, consistency conditions are called c^. As a consistency concept consists of 
a semantic mapping into a common semantic domain and conditions specified 
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Consistency Concept 




Fig. 1. Visualization of consistency concept 

on the syntax and within the semantic domain, a consistency concept can be 
viewed as a sort of integration of submodels. 

Within our approach, we can define different consistency concepts for a mod- 
eling language. As a consequence, a model can be consistent with respect to one 
consistency concept but inconsistent with respect to another consistency con- 
cept. This is motivated by different application domains, development processes 
and platforms a modeling language can be applied to and in contrast to the idea 
that a modeling language comes with pre-defined consistency concepts in the 
language specification. 

The motivation that gives rise to defining a consistency concept is called a 
consistency property. Such a consistency property is a model-independent de- 
scription of a property that a model should have. A consistency property can 
be informally characterized by stating what it ensures i. e. what characteristics 
a model must have that conforms to the consistency property. Examples for 
consistency properties include syntactic correctness, trace consistency or timing 
consistency. 

On the basis of consistency properties and consistency concepts, we can define 
consistency checks. A consistency check is a description how, given a model 
and a consistency condition, to decide whether or not the model fulfills the 
consistency condition. As a consequence, consistency checks can be thought of 
definining the fulfillment relation between a model and a consistency condition. 
Consistency checks can be performed using theorem proving, model checking [5] 
or by executing specialized algorithms [6]. 

Given a consistency condition and a concrete model, we can identify those 
submodel types of the larger model that lead to the inconsistency. This allows 
the distinction between consistency problem types and consistency problem in- 
stances: A consistency problem type is a configuration of submodel types that 
may give rise to the violation of a consistency condition. On the contrary, a 
consistency problem instance is a configuration of submodels such that each 
submodel corresponds to a submodel type of a given consistency problem type 
violating the consistency condition. This distinction between consistency prob- 
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Fig. 2. Layers of consistency 

lem type and instance is similar to the type-instance notions commonly known 
from object-orientation. Note that a consistency concept can also be thought of 
as one solution of a consistency problem type. 

In this section, we have introduced a generic definition of consistency. The 
terms in our definition of consistency lead to a layered approach to consistency, 
illustrated in Figure 2. Given a modeling language, in the property layer, dif- 
ferent properties exist that drive the definition of the consistency concept. A 
consistency concept comprises a number of consistency conditions and a seman- 
tic domain (not shown in the figure but cf. Figure 1). Once the conditions are 
determined, consistency checks are defined which verify or validate a consistency 
condition. 

2.2 Characteristics of Consistency Problems 

Consistency problems can be characterized on the one hand according to the 
situation they occur and on the other hand depending on the consistency con- 
ditions. 

One problem of consistency arises in cases where a model consists of dif- 
ferent submodels because a system is modeled from different viewpoints [2, 13]. 
This allows the concentration on different aspects in different submodels. How- 
ever, different viewpoint specifications must be consistent and not contradictory, 
because the implementation of such an inconsistent model would otherwise be 
infeasible. This type of consistency problem we will call horizontal consistency. 

Another quite different problem of consistency arises when a model is trans- 
formed into another model by replacing one or more submodels. It is then de- 




162 



J.M. Kiister and G. Engels 



sirable that the replaced submodel is a refinement of the previous submodel, in 
order to keep the overall model consistent. This type of consistency problem we 
will call vertical consistency. Vertical consistency problems are often induced by 
a development process which prescribes how and when models are iteratively 
refined. 

A quite different characterization is obtained by looking at the consistency 
conditions for a consistency problem. Here we can distinguish between syntac- 
tic consistency conditions and semantic consistency conditions. In general, con- 
sistency can be considered a semantic property. However, in order to ensure 
consistency, a number of inconsistent models can already be detected by regard- 
ing their syntax which means that the semantic property of consistency can be 
established by formulating syntactic consistency conditions. 

Additionally, we can make a distinction between syntactic consistency and se- 
mantic consistency. Concerning horizontal consistency problems, syntactic con- 
sistency ensures that the overall model consisting of submodels is syntactically 
correct. With regards to vertical consistency problems, syntactic consistency en- 
sures that changing of one part of the model within the development process still 
results into a syntactically correct model. With respect to a horizontal consis- 
tency problem, semantic consistency requires models of different viewpoints to 
be semantically compatible with regards to the aspects of the system which are 
described in the submodels. For vertical consistency problems, semantic consis- 
tency requires that a refined model is semantically consistent with the model it 
refines. 

In this section, we have introduced a characterization of consistency prob- 
lems, using our notion of consistency. We have clarified the notions of syntactic 
and semantic consistency and horizontal and vertical consistency. Such charac- 
terizations will prove helpful when identifying consistency problem types in a 
given development process. In the next section, we will introduce the idea of 
an explicit consistency management on the basis of consistency properties and 
consistency concepts. 

2.3 The Notion of Consistency Management 

Given a set of models and a development process, it arises the question how to 
ensure consistency of such models within the development process. Obviously, 
this requires specific activities taken including the definition of consistency con- 
ditions, the specification when consistency conditions are checked and what to 
do in the case of inconsistencies in order to resolve these. We thus need a sort 
of management of consistency and introduce the term consistency management. 
The importance of consistency management has been apparent in other disci- 
plines of computer science such as databases and programming languages (see 
e. g. Tarr et al. [28]). In general, a consistency management process is a process 
in the larger software engineering process. The goal of a consistency management 
process is to define and ensure a certain form of consistency of models. 

In order to generally ensure the consistency of models, the foundation of any 
consistency management is the ability to decide whether a model composed of 
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submodels is consistent or not. As a consequence, consistency management relies 
on a so-called constituent layer consisting of consistency properties, consistency 
concepts and consistency checks. In addition to these basic constituents, there 
might also be further specialized constituents. 

Consistency management also involves dealing with consistency within a de- 
velopment process. This leads to a so-called process layer of consistency man- 
agement. Here it must be determined how to organize the constituents within a 
consistency management process i. e. how to make use of the constituents to form 
a consistency management process. For example, it must be prescribed which 
consistency checks should be performed when and in which order. This includes 
the description when to, given a concrete model consisting of submodels, look for 
potential inconsistencies. If an inconsistency occurs, then it must be prescribed 
within the process when to handle and resolve it, if possible. 

A consistency management process is described by activities and stakehold- 
ers performing the activities. Activities include when to locate potential incon- 
sistencies within models and when to perform a consistency check associated 
to a consistency condition. In addition to these general activities, consistency 
management may also involve the description of how to avoid rechecking of con- 
sistency conditions and how to organize consistency checks in order to achieve 
consistency with respect to all consistency conditions. 

In Figure 3 consistency management is illustrated. In the lower part, the 
development process, modeling language and application domain are visualized. 
On top of them, a consistency management approach is shown being composed of 
consistency properties, consistency concepts, consistency checks and the consis- 
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tency management process. Note that we distinguish between such a specific con- 
sistency management approach and the overall field of consistency management. 

2.4 Related Approaches 

Existing approaches can be categorized into several categories. The first cat- 
egory contains approaches where a particular consistency problem is tackled. 
For instance, Fradet et al. [15] propose an approach to consistency checking of 
diagrams consisting of nodes and edges with multiplicities. They distinguish be- 
tween generic and instance graphs and define the semantics of a generic graph 
to be the set of instance graphs that fulfill the constraints of the generic graph. 
Consistency is then defined to be equivalent to the semantics of the generic 
graph being not an empty set. Consistency checking is then performed by solv- 
ing a system of linear inequalities derived from the generic graph. Also in this 
category falls the approach by Li et al. [24] who analyze timing constraints 
of sequence diagrams for their consistency solving systems of linear inequali- 
ties. 

Another category can be seen in approaches that achieve consistency of 
object-oriented models by completely formalizing them, thereby integrating all 
models into one semantic domain. Moreira and Clark [25] translate object- 
oriented analysis models to LOTOS in order to detect inconsistencies. Cheng 
et al. [4] formalize OMT models in terms of LOTOS specifications. Using these 
specifications, they perform consistency analysis using tools for state exploration 
and concurrency analysis. Grosse-Rhode [18] integrates all models by translating 
them into transformation systems. The problem involved with completely for- 
malizing models is that the application is then restricted to certain consistency 
problems mirrored by the choice of semantic domain. For example, a formal- 
ization in terms of LOTOS is not capable of dealing with consistency problems 
involving the aspect of time because LOTOS does not support this aspect. For 
a general-purpose modeling language such as UML, different application do- 
mains may give rise to quite different consistency problems which are difficult 
to treat within one formalization, not to speak of the numerous problems of for- 
malizing UML itself. As an example, for some applications modeled with UML, 
consistency problems involving the aspect of time might be of no relevance at 
all whereas in other applications (e. g. real-time applications), timing consis- 
tency is of high importance. As a consequence, approaches involving a complete 
formalization are currently not capable of dealing with all the consistency prob- 
lems arising within the development with UML in various application domains 
involving quite different sets of consistency problems. 

A third category can be seen in approaches that deal with consistency of 
models that are not object-oriented. Zave et al. [31] define consistency based on 
a translation into logics and define a set of partial specifications to be consistent 
if and only if its composition is satisfiable. Their approach therefore requires 
that models are given a semantics in form of logics. Boiten et al. [3] define 
consistency on the basis of development relations and define a set of partial 
specifications to be consistent if and only if a common development relation 
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exists. This approach requires the existence of a formal semantics for models 
and the concept of development relations defined for models used within the 
development process. 

Another, quite different, category of related work can be seen in approaches 
that deal with inconsistency management [26] [17]. Rather then trying to achieve 
complete consistency, these approaches tackle the problem of managing incon- 
sistencies. This management is based on the location of inconsistencies and the 
appropriate handling (resolving of inconsistency or tolerating it) . Concentrating 
on the process of consistency management, they assume that the foundation of 
consistency management in terms of consistency conditions is already in place. 

From our discussion of related work we can see that our generic definition 
of consistency is applicable: In the first category, we are dealing with quite 
different semantic domains such as systems of linear inequalities or the set of 
instance graphs. In the second category, semantic domains used are LOTOS 
or transformation systems and in the third category first-order logic is used 
as semantic domain. On the contrary to existing approaches, we concentrate 
on the technical mechanisms that are used to define consistency in different 
scenarios. This will enable us to describe a general methodology how to deal with 
consistency in a situation as currently encountered by the UML: consistency 
is not defined as part of the standard and further, quite different consistency 
concepts are needed depending on the development context. Before we move on 
to our methodology, we will first discuss characteristics of consistency problems. 

In the following section, we present an approach to consistency management 
based on the idea of partially formalizing the model for enabling consistency 
checks. As a consequence, our approach can be regarded as a combination of the 
approaches in the first and the second category. As our approach also comprises 
the idea of consistency management within a development process, it is also 
related to the fourth category although the idea of tolerating inconsistencies is 
not in focus. 



3 A General Methodology for Consistency Management 

Due to the unclear semantics and different employments of UML within the 
development process, a general concept of consistency management for UML 
models is missing [7] . Concerning syntactic consistency, this type of consistency 
is partially achieved by defining well-formedness rules on the metamodel. Due 
to the absence of a generally-accepted formal semantics, semantic consistency 
is currently not well-supported. Nevertheless, semantic consistency is of great 
importance and must be dealt with. In our opinion, waiting for a complete for- 
malization of UML models is not feasible as we need consistency management 
now and the existence of a complete formalization of UML models applicable to 
all usages of UML models is doubtful. Another problem is the informal develop- 
ment process followed which leads to the need of flexible notions of consistency. 

Our approach to consistency management is based on the following obser- 
vation: The fundamental question to answer when given a model consisting of 
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submodels and a consistency property is whether there exists an integration of 
the submodels fulfilling the consistency property. Although a formally defined 
semantics does not exist, it is still possible to restrict oneself to certain aspects 
of models and then determine whether an integration fulfilling the consistency 
property exists. The concept of our approach is illustrated in Figure 4. Sub- 
models used within development overlap in a number of aspects. For ensuring 
consistency, submodels are integrated into a common semantic domain, that 
supports these overlapping aspects. Note that our approach also applies to a 
submodel type with overlapping aspects, to deal with consistency problem types 
within a submodel type. If a concrete model cannot be integrated, then it is 
inconsistent. 

Our idea of partially formalizing models for the purpose of consistency man- 
agement yields a better degree of consistency than without any formalization 
and overcomes the problems associated with complete formalizations. It allows 
to conduct suitable consistency checks for consistency problems within quite dif- 
ferent application domains by using different semantic domains. Our approach 
of partially formalizing models therefore uses the strength of completely formal- 
izing approaches because it allows precisely stated consistency conditions. On 
the other hand, it also overcomes the disadvantage of restricted applicability by 
the idea of partial formalization within a suitable semantic domain. Further- 
more, partial formalizations are often easier to handle than one large complex 
complete formalization trying to capture all possible aspects. 

Given the goal of achieving consistency by constructing suitable partial for- 
malizations, each providing a consistency concept, we are faced with the problem 
of how to come up with suitable consistency concepts, consistency conditions, 
consistency checks and how to integrate all these into a consistency management 
process. 
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Our approach to consistency management is to describe a methodology for 
consistency management. By a methodology, we understand a set of methods 
and techniques [16] that are used for consistency management. A method con- 
tains a set of activities and general guidelines how to execute the activities. 
Insofar, our methodology contains activities and techniques that yield a partic- 
ular consistency management process, taking into account different application 
domains and development processes. The methodology can be applied to differ- 
ent problem situations and therefore constitutes a set of methods rather than 
one particular method. 

In Figure 5, the idea of defining a methodology is illustrated, building on the 
explanation of consistency management in the previous chapter. On the right, 
the ingredients of a consistency management approach are shown which are con- 
sistency properties, consistency concepts, consistency checks and a consistency 
management process. On the left, we introduce the methodology, which takes as 
input the development process, the modeling language and the application do- 
main and then produces the consistency management approach. In the following, 
we describe the activities of our methodology. 

Activity 1: Identification of Consistency Problem Types. The goal of this activ- 
ity is the identification of all relevant consistency problem types. The basis for 
the identification of consistency problem types is obtained by discovering which 
submodel types model the same aspects of the system and which aspects con- 
sistency properties affect. Due to the common description of aspects in different 
submodel types or the aspectual overlap of a submodel type and a consistency 
property, consistency problems may occur. These consistency problems are iden- 
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tilled, categorized to consistency problem types and informally defined, including 
an informal description of the desired consistency condition to hold. Each con- 
sistency problem type must be documented. 

Activity 2: Formalization of a Consistency Problem Type. This activity aims 
at establishing a formal consistency concept for each consistency problem type. 
For each consistency problem type identified, we choose an appropriate seman- 
tic domain. In this semantic domain, those aspects that lead to the consistency 
problem type must be expressible (i. e. the aspects where submodels overlap). 
Furthermore, tool support should be available for the semantic domain in or- 
der to facilitate consistency checks. All aspects of the model that lead to the 
identified consistency problem type must be mapped into the semantic domain. 
Formal consistency conditions must be formulated that correspond to the infor- 
mal description of consistency conditions. The definition of the partial mapping 
is crucial for the correctness of later defined consistency conditions and no as- 
pects of the model should be left out that influence the consistency of the model. 
On the other hand, only those aspects of the model should be mapped into the 
semantic domain that are important for the consistency because otherwise anal- 
ysis may get too complex. 

Activity 3: Operational Specification of Model Transformations. Each formal con- 
sistency concept must be transformed such that models can be mapped into the 
semantic domain in an automated way. For that purpose, model transformations 
for the mappings of the consistency concept will be introduced. Further, it must 
be taken care of that consistency conditions can also be generated automatically. 

Activity 4- Specification of Consistency Checks. For each consistency problem 
type, a consistency check is defined that validates the formal consistency con- 
ditions. For each consistency problem type, it must also be determined what to 
do in case of an inconsistency. The handling of such an inconsistency involves 
either the resolution or tolerance of the inconsistency. 

Activity 5: Embedding of Consistency Management into Development Process. 
For each consistency problem type, it must be specified when to deal with it in an 
existing development process. The order of consistency checks to be performed 
by grouping the consistency conditions must be determined and fixed within 
the development process. The existing development process must be adapted in 
so far that concrete activities must be introduced that define when to perform 
which consistency check. These activities include the location of inconsistencies 
in a concrete model and the handling of inconsistencies. 

The final result of having performed all these meta-level activities is a devel- 
opment process that contains a concrete consistency management process. It is in 
so far concrete that it defines consistency management for a given development 
process, application domain and modeling language. The concrete consistency 
management process, together with a concrete development problem, is simulta- 
neously the starting situation for the activities performed on the concrete level 
which are the location and handling of inconsistencies. 
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Fig. 6. Consistency problem example 



In the following section, we sketch the application of the activities to an 
example consistency problem type. Then, we discuss how the methodology can 
be supported in order to be performable by the software engineer. 



4 Application 

In this section, we sketch the application of our methodology to a sample con- 
sistency problem type. 

In Figure 6, two structured objects capsl and caps2 are shown, joined by a 
connector via two ports pi and P 2 - Attached to this connector is a collabora- 
tion with its behavior modeled in the protocol statechart SCprot- The behavior 
of the structured objects is specified in two statecharts, named SC\ and SC 2 - 
Intuitively, the interaction arising from executing the statecharts of the struc- 
tured objects should conform to the protocol specified in the protocol statechart. 
Activity 1 of the methodology will yield as outcome that there exists a consis- 
tency problem type in this case (called protocol consistency), together with the 
informal consistency condition formulated above. 

Activity 2 aims at constructing a formal consistency concept. In this case, we 
will choose CSP [21] as a semantic domain. The formal method CSP is supported 
by the model checker FDR [14] for evaluating consistency conditions formulated 
in CSP. We then have to define partial mappings of the statecharts and the 
protocol statechart into the semantic domain of CSP. In other words, the consis- 
tency concept consists of the submodel types protocol statechart, the statechart 
of structured objects and the collaboration, mappings of these submodel types 
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Fig. 7. Two rules for statechart translation 



into CSP and a set of consistency conditions formalizing the informally noted 
form of consistency. 

For the consistency problem of protocol consistency, we can define two dif- 
ferent consistency conditions: For weak protocol consistency we require that all 
traces of the interaction of the structured object statecharts must be contained 
in the set of traces of the protocol statechart. For strong protocol consistency 
we additionally assume that all the traces of the protocol statechart must occur 
in the system. Extending the statechart SC\ by introducing another transition 
sending another event will violate the condition of weak protocol consistency. 
Removing the last transition of SC 2 will violate the condition of strong protocol 
consistency. In previous work (e.g. [22]), we have reported on the details of such 
a consistency concept which are beyond the scope of this work. 

Activity 3 aims at making the consistency concept operational. In our case, 
the partial translations of the submodel types must be defined in such a way that 
they are executable automatically. We have recently explored a graph transfor- 
mation approach [19] [8] [23] which allows the translation to be specified by a set 
of compound graph transformation rules. In our case, such a compound graph 
transformation rule consists of two parts, a source production rule specified by a 
UML metamodel extract and a target production rule in the semantic formalism, 
here CSP. As we do not want to change the source model, the source production 
is the identical production, with equal left and right side. In Figure 7, two com- 
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pound graph transformation rules are shown for translating statecharts to CSP, 
inspired by existing work of Hiemer [20] . 

Graph transformation rules of this form can then be used to specify a model 
transformation from a given source UML model to a target CSP model. The 
semantics of rule applications is briefly described as follows: Given a concrete 
UML model, a match for the UML metamodel extract is searched for in the 
concrete UML model. Once such a match is found, a match of the left side of 
the target production is searched for in the CSP model. Once the two matches 
have been found, the match of the CSP model is replaced by the right side of 
the target production. Note that using these kind of graph transformation rules, 
no additional specification language for describing the transformation is needed: 
Each rule is basically expressed in terms of the source and target language, in 
our case in UML and CSP, enriched with mechanisms for cSommon variables and 
placeholders. A detailed explanation of this model transformation approach can 
be found in [19] and [8]. The problem of ensuring termination and confluence of 
such rule-based transformations is treated in [23]. For this activity, also related 
model transformation approaches such as the one by Whittle [30] or Varro et al. 
[29] could be used. 

In Activity 4, the consistency check must be defined, on the basis of the 
previously developed transformation units. Typically, such a consistency check 
can be specified by using activity diagram for modeling the overall workflow. 
Such an activity diagram will define for example that given a situation like in 
Figure 6, first the statecharts of the structured objects are translated to CSP 
and then the protocol statechart. The overall result will then be fed into a model 
checker and the result will be interpreted. 

On the basis of such consistency checks, an overall development process can 
be modified, by introducing consistency checks. For that, the order of consistency 
checks must be determined and also how inconsistency handling influences the 
overall consistency of a model. The details of these tasks are defined in Activity 
5. In our sample application we have not described a development process but 
concentrated on one consistency problem. For a more detailed example of this 
activity, the reader is referred to [22]. 



5 The Consistency Workbench 

In this section, we provide an overview of the consistency workbench, a research 
prototype that has been developed for consistency management. In principle, the 
software engineer needs support for all activities of the methodology. Neverthe- 
less, one quickly realizes that adequate tool support for all activities is difficult 
to provide. For example, the formalization process in Activity 2 cannot be sup- 
ported by tools. In the following, we describe the main functionalities of the 
consistency workbench: 

1. Definition of Consistency Problem Catalogue. Using a template that contains 
a name, classification, and informal description of the problem, a pattern of the 
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meta model to localize potential occurrences, and an example, the Consistency 
Workbench allows the software engineer to define a catalogue of problem types 
that may be reused in different development processes. 

2. Definition of Transformations. By a set of graph transformation rules, con- 
trolled by a simple control flow language based on regular expressions, the soft- 
ware engineer can define translations of models into a semantic domain. Each 
such transformation rule consists of two parts, a source and a target transfor- 
mation rule (see Figure 8), coupled by the use of common variables. The source 
transformation rule is specified by providing a UML metamodel extract, repre- 
sented by an XMl description which is an existing exchange format for UML 
models. Note that other than the concept explained in Figure 7, the tool also 
supports full source productions which also enables changes of the UML model 
(not implemented at the moment). Rather than writing an XMl description by 
hand, we currently use existing UML CASE tools for designing the UML meta- 
model extract. The generated XMl description can then be used after slight 
modifications. The target transformation rule is defined by providing a trans- 
formation rule in a context-free grammar notation for textual languages such 
as CSP [21]. Here, additional iteration constructs are provided for looping over 
multi-objects matched at the UML side. 

3. Definition of Consistency Checks. Based on previously defined transformation 
units, the software engineer can define consistency checks for a problem type in 
the catalogue. Such a consistency check is modeled as a workflow consisting of 
several activities, like the localization of potential problems based on the pat- 
tern defined in 1., the translation defined in 2., the generation of a consistency 
condition in the target language defined by a transformation in 2., and its ver- 
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Fig. 9. Defining a Consistency Check 

ification by an external tool (e.g., a model checker). In Figure 9, the definition 
of a consistency check is illustrated. 

Execution of Consistency Checks. Consistency checks can then be executed on 
a concrete UML model following the workflows defined. For that purpose, UML 
models constructed with UML CASE tools such as Poseidon [1] can be loaded 
into the consistency workbench. Currently, such models can be visualized but 
not edited. For a given model, a consistency check can be manually triggered. 
Intermediate results of the consistency check such as models constructed dur- 
ing execution of the model transformations can be accessed in the consistency 
workbench. The result of a consistency check is currently displayed in the con- 
sistency workbench by showing the result of the model checker, together with a 
predefined explanation. 

Being a research prototype, the consistency workbench has currently several 
limitations: The capability of illustrating an inconsistency by means of a coun- 
terexample expressed in an additional UML sequence diagram has not yet been 
implemented. Further, complex transformation units have been developed for 
translating statecharts to CSP but, apart from that, no other semantic domain 
has been used in the consistency workbench so far. Nevertheless, the main idea 
of our approach can be considered feasible: by systematically developing par- 
tial translations of UML models into suitable semantic domains, the consistency 
workbench could evolve into a technical support tool for the software engineer. 



6 Conclusion 

In this paper, we have presented our approach to consistency management 
object-oriented models. Motivated by the situation that currently a general ap- 
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proach for consistency management is not provided by the UML, we have first 
introduced the concepts for consistency management such as consistency condi- 
tion, consistency concept, consistency check and consistency management. Using 
this thorough investigation of consistency, we have explained how our general 
methodology builds a consistency management approach, depending on the mod- 
eling language, application domain and development process. Activities of this 
methodology have been discussed. The overall methodology has been demon- 
strated by applying it to an example consistency problem type and sketching 
the outcome of each activity. Finally, we have reported on the tool Consistency 
Workbench which is a research prototype designed for supporting the software 
engineer in the complex task of consistency management. Due to the nature of 
this paper being a summary and overview paper, we have not been able to pro- 
vide the full details of all activities. For that the reader is referred to the existing 
publications. 

Future work can be performed into several directions: With regards to our 
general methodology, by applying it to real-world development processes, it can 
be validated and refined. Furthermore, more consistency problems occuring in 
UML-based development will be discovered and treated which will lead to a 
number of predefined model transformations. Further, also suitable abstraction 
mechanisms must be developed. In the context of our work, it has turned out 
that this issue is vital for being able to perform consistency checking on larger, 
real-world models. This is due to the underlying approach of model checking 
which suffers from the well-known state explosion problem. With regards to tool 
support, we envisage that our consistency workbench could be integrated into 
an existing CASE tool. 



References 

1. M. Boger, T. Sturm, E. Schildhauer, and E. Graham. Poseidon for UML Users 
Guide. Gentleware AG, 2003. Available under http://www.gentleware.com. 

2. E. Boiten, H. Bowman, J. Derrick, P. Linington, and M. Steen. Viewpoint Consis- 
tency in ODP. Computer Networks, 34(3):503-537, August 2000. 

3. E. Boiten, H. Bowman, J. Derrick, and M. Steen. Viewpoint consistency in Z 
and LOTOS: A case study. In J. Fitzgerald, C. B. Jones, and P. Lucas, editors, 
FME’97: Industrial Applications and Strengthened Foundations of Formal Methods 
(Proc. 4th Inti. Symposium of Formal Methods Europe, Graz, Austria, September 
1997), volume 1313 of Lecture Notes in Computer Science, pages 644-664. Springer- 
Verlag, Heidelberg, September 1997. 

4. B. Cheng, L. Campbell, and E. Wang. Enabling Automated Analysis Through 
the Formalization of Object-Oriented Modeling Diagrams. In Proceedings of IEEE 
International Conference on Dependable Systems and Networks, pages 433-442. 
IEEE Computer Society, 2000. 

5. E. M. Clarke, O. Grumberg, and D. A. Peled. Model Checking. The MIT Press, 
Cambridge, MA, 1999. 

6. A. Egyed. Heterogenous View Integration and its Automation. Dissertation, Uni- 
versity of Southern California, 2000. 




Consistency Management Within Development of Components 175 



7. G. Engels and L. Groenewegen. Object-Oriented Modeling: A Roadmap. In An- 
thony Finkelstein, editor, Future Of Software Engineering 2000, pages 105-116. 
ACM, June 2000. 

8. G. Engels, R. Heckel, and J. M. Kiister. Rule-Based Specification of Behavioral 
Gonsistency Based on the UML Meta-model. In M. Gogolla and C. Kobryn, edi- 
tors, UML 2001 - The Unified Modeling Language. Modeling Languages, Concepts, 
and Tools., fth International Conference, Toronto, Canada, October 1-5, 2001, 
Proceedings, volume 2185 of LNCS, pages 272-287. Springer- Verlag, 2001. 

9. G. Engels, R. Heckel, and J. M. Kiister. The Gonsistency Workbench - A Tool for 
Gonsistency Management in UML-based Development. In P. Stevens, J. Whittle, 
and G. Booch, editors, UML 2003 - The Unified Modeling Language. Modeling 
Languages and Applications. 6th International Conference, San Francisco, October 
20-24, USA, Proceedings, volume 2863 of LNCS, pages 356-359. Springer- Verlag, 
2003. 

10. G. Engels, J. M. Kiister, and L. Groenewegen. Consistent Interaction of Software 
Components. In Proceedings of Sixth International Conference on Integrated Design 
and Process Technology (IDPT 2002), 2002. 

11. G. Engels, J. M. Kiister, and L. Groenewegen. Consistent Interaction of Software 
Components. Transactions of the SDPS: Journal of Integrated Design and Process 
Science, 6(4):2-22, December 2002. 

12. G. Engels, J. M. Kiister, L. Groenewegen, and R. Heckel. A Methodology for 
Specifying and Analyzing Consistency of Object-Oriented Behavioral Models. In 
V. Gruhn, editor. Proceedings of the 8th European Software Engineering Conference 
(ESEC), pages 186-195. ACM Press, 2001. 

13. A. Finkelstein, D. Gabbay, A. Hunter, J. Kramer, and B. Nuseibeh. Inconsistency 
Handling in Multi-Perspective Specifications. In Ian Sommerville and Manfred 
Paul, editors. Proceedings of the Fourth European Software Engineering Confer- 
ence, pages 84-99. Springer- Verlag, 1993. 

14. Formal Systems Europe (Ltd). Failures-Divergence-Refinement: FDR2 User Man- 
ual, 1997. 

15. P. Fradet, D. Le Metayer, and M. Perin. Consistency Checking for Multiple View 
Software Architectures. In O. Nierstrasz and M. Lemoine, editors, ESEC/FSE ’99, 
volume 1687 of Lecture Notes in Computer Science, pages 410-428. Springer- 
Verlag/ ACM Press, 1999. 

16. C. Ghezzi, M. Jazayeri, and D. Mandrioli. Fundamentals of Software Engineering. 
Prentice-Hall, 1991. 

17. G. Ghezzi and B. A. Nuseibeh. Special Issue on Managing Inconsistency in Software 
Development (2). IEEE Transactions on Software Engineering, 25(11), November 
1999. 

18. M. Grosse-Rhode. Integrating Semantics for Object-Oriented System Models. In 
F. Orejas, P. G. Spirakis, and J. van Leeuwen, editors. Proceedings of ICALP’Ol, 
LNGS 2076, pages 40-60. Springer- Verlag, 2001. 

19. R. Heckel, J. M. Kiister, and G. Taentzer. Towards Automatic Translation of 
UML Models into Semantic Domains. In H.-J. Kreowski and P. Knirsch, editors. 
Proceedings of the Appligraph Workshop on Applied Graph Transformation, pages 
11-22, March 2002. 

20. J.-J. Hiemer. Statecharts in CSP: Ein Prozessmodell in CSP zur Analyse von 
STATEMATE-Statecharts. DrKovac Verlag, Hamburg, 1999. 

21. G. A. R. Hoare. Communicating Seguential Processes. Prentice Hall, 1985. 

22. J. M. Kiister. Consistency Management of Object-Oriented Behavioral Models. 
PhD thesis. University of Paderborn, March 2004. 




176 



J.M. Kiister and G. Engels 



23. J. M. Kiister, R. Heckel, and G. Engels. Defining and Validating Transformations 
of UML Models. In J. Hosking and P. Cox, editors, IEEE Symposium on Human 
Centric Computing Languages and Environments (HCC 2003) - Auckland, October 
28 - October 31 2003, Auckland, New Zealand, Proceedings, pages 145-152. IEEE 
Computer Society, 2003. 

24. X. Li and J. Lilius. Timing Analysis of UML Sequence Diagrams. In Robert France 
and Bernhard Rumpe, editors, UML’99 - The Unified Modeling Language. Beyond 
the Standard. Second International Conference, Fort Collins, CO, USA, October 
28-30. 1999, Proceedings, volume 1723 of LNCS, pages 661-674. Springer- Verlag, 
1999. 

25. A. Moreira and R. Clark. Combining Object-Oriented Modeling and Formal De- 
scription Techniques. In M. Tokoro and R. Pareschi, editors. Proceedings of the 8th 
European Conference on Object-Oriented Programming (ECOOP’94), pages 344 - 
364. LNCS 821, Springer- Verlag, 1994. 

26. B. Nuseibeh, S. Easterbrook, and A. Russo. Making Inconsistency Respectable in 
Software Development. Journal of Systems and Software, 58(2):171-180, Septem- 
ber 2001. 

27. Object Management Group (OMG). OMC Unified Modeling Language Specifica- 
tion, Version 1.5. OMG document formal/03-03-01, March 2003. 

28. P. Tarr and L. A. Clarke. Consistency Management for Complex Applications. 
Technical report. Technical Report 97-46, Computer Science Department, Univer- 
sity of Massachusetts at Amherst, 1997. 

29. D. Varro, G. Varro, and A. Pataricza. Designing the Automatic Transformation 
of Visual Languages. Science of Computer Programming, 44(2):205-227, August 
2002 . 

30. J. Whittle. Transformations and Software Modeling Languages: Automating 
Transformations in UML. In J.-M. Jezequel, H. Hussmann, and S. Gook, edi- 
tors, UML 2002 - The Unified Modeling Language. 5th International Conference, 
Dresden, Germany, September 30 - October f, 2002, Proceedings, volume 2460 of 
LNCS, pages 227-242. Springer- Verlag, 2002. 

31. P. Zave and M. Jackson. Conjunction as Composition. ACM Transactions on 
Software Engineering and Methodology, 2(4):379-411, October 1993. 




Community on the Move: 
Architectures for Distribution and Mobility 



Jose Luiz Fiadeiro' and Antonia Lopes^ 

‘ Department of Computer Science, University of Leicester 
University Road, Leicester LEI 7RH, UK 
j ose@f iadeiro . org 

^ Department of Informatics, Faculty of Sciences, University of Lisbon 
Campo Grande, 1749-016 Lisboa, PORTUGAL 
mal@di .fc.ul.pt 



Abstract. Mobility has become a new factor of complexity in the construction 
and evolution of software systems. In this paper, we report on the extensions 
that we have made to Community, a prototype language for architectural de- 
scription, with modelling techniques that support the incremental and composi- 
tional construction of location-aware systems. We illustrate, around an exam- 
ple, how the proposed extensions lead to a true separation of concerns between 
computation, coordination and distribution in architectural models. 



1 Introduction 

The evolution of the internet and wireless communication is inducing an unprece- 
dented and unpredictable variety and complexity on the roles that software can play. 
Now that software development methods and techniques were finally starting to cope 
with the building of distributed applications over static configurations, mobility is 
introducing an additional factor of complexity due to the need to account for the 
changes that can occur, at run time, at the level of the topology over which compo- 
nents perform computations and interact with one another. 

Architectural modelling techniques [16] have helped to tame the complexity of 
building distributed applications over static networks by enforcing a strict separation 
of concerns. On the one hand, we have what in systems can account for the opera- 
tional aspects (what we call “computations” in general) that are responsible for the 
behaviour that individual components ensure locally, e.g. the functionality of the 
services that they offer. On the other hand, we have the mechanisms that control the 
behaviour of individual components and coordinate the interconnections among 
groups of components, so that global properties of systems emerge. 

This separation between “Computation” and “Coordination” [11] supports the ex- 
ternalisation, and definition as first-class citizens, of the rules according to which the 
joint behaviour of given components of a system needs to be controlled. As a conse- 
quence, one can build complex systems from simpler components by superposing the 
architectural connectors that coordinate their interactions. This gross modularisation 
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of systems can also be progressively refined, in a compositional way, by adding detail 
to the way computations execute in chosen platforms and the communication proto- 
cols that support coordination. Compositionality means that refinements over one of 
the dimensions can be performed without interfering with the options made already 
on the other one. 

The levels of compositionality that architectural approaches can bring to software 
development also apply to evolution [2]. On the one hand, connectors can be changed 
or replaced without interfering with the code that components execute locally to per- 
form the computations required by system services. On the other hand, the code run- 
ning in the core components of the system can itself be evolved, e.g. optimised, with- 
out interfering with the connectors, for instance with the communication protocols 
being used for interconnecting components. 

The major challenge that we face, and that justifies this paper, is to take this sepa- 
ration of concerns one step further and address distribution/mobility aspects as a first- 
class architectural dimension. On the one hand, it seems clear that, when we 
(re)configure a system, we need to take into account the support that locations provide 
for the operational/computational aspects of the individual components, and the abil- 
ity for the interconnections to be effective over the communication network. For 
instance, it is essential that a system as a whole may self-adapt to changes occurring 
in the network topology, either to maintain agreed levels of quality of service, or to 
take advantage of new services that may become available. On the other hand, we 
need to be able to understand and refine global properties of a system separately in 
each of the three dimensions. 

In this paper, we report on work that we are pursuing within the lST-2001-32747 
project AGILE - Architectures for Mobility - with the aim of extending the level of 
separation and compositionality that has been obtained for computation and coordina- 
tion to distribution/mobility. By focusing on an example - an airport luggage han- 
dling system - that, in past papers, we handled both in a location-transparent way [19] 
and in a preliminary experiment of the new primitives [3], we show how we can sup- 
port the construction and evolution of location-aware architectural models by super- 
posing explicit connectors that handle the mobility aspects. In this sense, this paper 
can be used as a companion to [13], which is where we have formalised the new ar- 
chitectural modelling techniques that we shall be discussing. 



2 Designing Location-Aware Components in Community 

Location-transparency is usually considered to be an important abstraction principle 
for the design of distributed systems. It assumes that the infrastructure masks the 
physical and logical distribution of the system, and provides location-transparent 
communication and access to resources: components do not need to know where the 
components to which they are interconnected reside and execute their computations, 
nor how they themselves move across the distribution network. 

Traditionally, architectural approaches to software design also adhere to this prin- 
ciple; essentially, they all share the view that system architectures are structured in 
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terms of components and architectural connectors. Components are computation loci 
while connectors, superposed on certain components or groups of components, ex- 
plicitly define the way these components interact. In this section, we focus on the 
way individual components are designed in Community with a special emphasis on 
the primitives that capture distribution and mobility aspects. 



2.1 Location-Unaware Components 

Community is a parallel program design language that is similar to Unity [6] and IP 
[10] in its computational model but adopts a different coordination model. More 
concretely, whereas, in Unity, the interaction between a program and its environment 
relies on the sharing of memory, Community relies on the sharing (synchronisation) 
of actions and exchange of data through input and output channels. 

To illustrate the way components can be designed in Community, and provide a 
fair idea of the range of situations that our approach can address, we use a variation of 
a problem that we previously developed in [3,19] - a typical airport luggage delivery 
system in which carts move along a track and stop at designated stations for handling 
luggage. 

In order to illustrate how incremental development is supported in Community, we 
start with a very high-level design of a cart: 

design Cart is 

prv busy: bool 

do move[] : -ibusy, false — > true 

D dock [busy] : -■busy, false — >busy' 

D undock [busy] : busy, false — > -ibusy' 

This design caters for the very basic description that we gave of a cart’s behaviour: 
the fact that it can move and stop at stations to handle luggage. In Community, com- 
ponents are designed having in mind the interactions that they can establish with other 
components in terms of exchanging data through communication channels and syn- 
chronising to perform joint actions. The design above does not mention any public 
channels because, at this stage, we have not identified any need for the cart to ex- 
change data with its environment. However, the cart needs to keep some internal data 
to know when it is parked at a station; this is modelled by the private channel busy. 
We call it channel because it can be used to exchange information between different 
components inside the cart, but we make it private to hide it from the environment. 

The actions that a component can perform are declared under “do” and their speci- 
fication takes the general form: 

g[D(g)]: L(g), U(g) -> R(g) 

where 

• D(g) consists of the local channels into which executions of the action can place 
values. This is normally called the write frame of g. We omit this set when it can 
be inferred from the assignments in R(g). Given a private or output channel v, we 
will also denote by D(v) the set of actions g such that vED(g). Hence, above. 
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move has an empty write frame and busy is in the write frames of dock and un- 
dock. 

• L(g) and U(g) are two conditions that establish the interval in which the enabling 
condition of any gnarded command that implements g mnst lie: the lower bound 
L(g) is implied by the enabling condition, and the upper bound U(g) implies the 
enabling condition. Hence, the enabling condition of g is fully determined only if 
L(g) and U(g) are equivalent, in which case we write only one condition. From a 
specification point of view, U(g) allows us to place requirements on the states in 
which the action should be enabled (progress) and L(g) allows us to restrict the 
occurrence of the action to given sets of states (safety). By setting U to false, as 
in the examples above, we are not making any requirements as to when we want 
the actions to be enabled; this is useful for being able to add requirements in an 
incremental way as illustrate below. For instance, restrictions on how a cart can 
move will certainly arise when taking into consideration other aspects of the sys- 
tem. On the other hand, each of the three actions was given a safety guard, basi- 
cally ensuring that carts do not move while docked at a station for handling lug- 
gage. 

• is a condition that uses primed channels to account for references to the val- 

ues that the channels take after the execution of the action. This is usually a con- 
junction of implications of the form pre id pos where pre does not involve primed 
channels. Each such implication corresponds to a pre/post-condition specification 
in the sense of Hoare. When R(g) is such that the primed channels are fully de- 
termined, we obtain a conditional multiple assignment, in which case we can use 
the notation that is normally found in programming languages v:=F(g,v)). 

Hence, we could have used busy:=true for R(dock) and busy:=false for 
R(undock). When the write frame DfgJ is empty, is tautological. This is the 
case of move. 

A Community design is called a program when, for every g£F, Ifg) and U(g) co- 
incide, and the relation R(g) defines a conditional multiple assignment. The behav- 
iour of a program is as follows. At each execution step, any of the actions whose 
enabling condition holds can be executed if requested, in which case its assignments 
are performed atomically. 

Actions can also be declared to be private, a situation not illustrated above, mean- 
ing that they cannot be shared with the environment of the component. Private ac- 
tions that are infinitely often enabled are guaranteed to be selected for execution infi- 
nitely often. A model-theoretic semantics of Community can be found in [15]. 



2.2 Location-Aware Components 

The design that we gave above does not take into account the fact that the cart can 
only dock when it reaches the station to which it has been sent, nor does it model the 
way a cart comes to know about its destination. The design below refines the previ- 
ous one with this kind of information: 
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design Located Cart is 
inloc pos 
in next : Loc 

prv busy@pos : bool , dest@pos:Loc 
do move[]@pos: -■busyApos;tdest , false — > true 
D dock [busy] @pos : -ibusyApos=dest, false — >busy:=true 

D undock [busy , dest] @pos : 

busyApos=dest , false — > busy : =f alse || dest:=next 

This design uses new primitives, some of which relate to the way we handle the 
notions of location, distribution and mobility. In Community, the underlying “space 
of mobility” is constituted by the set of possible values of a special data type with a 
designated sort Loc and whatever operations are necessary to characterise locations, 
for instance hierarchies or taxonomies. The only requirement that we make is for a 
special position to be distinguished; its role will be discussed further below. 

By not adopting a fixed notion of location, Community can remain independent of 
any specific notion of space and, hence, be used for designing systems with different 
kinds of mobility. For instance, for physical mobility, the space is, typically, the 
surface of the earth, represented through a set of GPS coordinates, but it may also be a 
portion of a train track represented through an interval of integers. In other kinds of 
logical mobility, space is formed by IP addresses. Other notions of space can be 
modelled, namely multidimensional spaces, allowing us to accommodate richer per- 
spectives on mobility. For instance, in order to combine logical mobility with secu- 
rity concerns, it is useful to consider locations that incorporate information about 
administrative domains. 

Community designs are made location-aware by associating their “constituents” 
— code and data — with “containers” that can move to different positions. Designs 
are not located: they can address components that are distributed across different 
locations. Hence, the unit of mobility, i.e., the smallest constituent of a system that is 
allowed to move, is fine-grained and different from the unit of execution. 

More precisely, location-awareness comes about in Community designs as fol- 
lows: 

• Location variables, or locations for short, can be declared as “containers” that can 
be moved to different positions. Locations can be input or output. Inputlocations, 
declared under inloc, are controlled by the environment and cannot be modified by 
the component. Hence, the movement of any constituent located at an input loca- 
tion is operated by the environment. Output locations, declared under outloc, can 
only be modified locally through assignments performed within actions and, 
hence, the movement of any constituent located at an output location is under 
the control of the component. In the case above, we declared only one location 
- pos - because the cart is not a distributed component. This location is declared 
as input because we want other components to be able to control the movement of 
the cart. 

• Each local channel x is associated with a location variable 1. We make this as- 
signment explicit by simply writing x@l in the declaration of x. The intuition is 
that the value of I indicates the current position of the space where the values of x 
are made available. A modification in the value of I entails the movement of x as 
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well as of the other channels and actions located at 1. Because the cart is not dis- 
tributed, busy has no choice but to be located at pos. 

• Every action g is associated with a set of location variables A(g) meaning that the 
execution of action g is distributed over those locations. In other words, the exe- 
cution of g consists of the synchronous execution of a guarded command in each 
of these locations: given lEA(g), g@l is the guarded command that g executes at 1. 
Again, because carts are not distributed, all the actions are located at pos. 

Notice that guarded commands may now include assignments involving the read- 
ing or writing of location variables. This is the case of the actions of the cart: they 
were refined in order to make use of locations. More precisely, we have now re- 
stricted the enabling of move to the situation in which the cart has not reached its 
destination, and dock and undock to when the cart is at its destination. 

The destination of the cart is kept in a private channel dest and updated before 
leaving the station by reading it from an input channel next. Input channels are used 
for reading data from the environment; the component has no control on the values 
that are made available in such channels. Notice that reading a value at a channel 
does not consume it: the value will remain available until it is changed by the envi- 
ronment. 

Input channels are assigned a distinguished output location - /I - usually omitted in 
designs. This location has the special value ± that is used whenever one wants to 
make no commitment as to the location of a channel or action. For instance, input 
channels are always located at A. because the values that they carry are provided by 
the environment in a way that is location-transparent; their location is determined at 
configuration time when they are connected to output channels of other components. 

Actions uniquely located at A model activities for which no commitments with re- 
spect to location-awareness have been mad. The reference to A in these cases is usu- 
ally omitted. This is what happened with our first design: all its constituents were 
assumed to be located at A. In later stages of the development process, the execution 
of such actions can be distributed over several locations, i.e. the guarded command 
associated with g@A can be split in several guarded commands associated with lo- 
cated actions of the form g@l, where / is a proper location. Whenever the command 
associated with g@A has been fully distributed over a given set of locations in the 
sense that all its guards and effects have been accounted for, the reference to g@/l is 
usually omitted. In the second design, we made location-awareness more explicit and 
introduced references to specific location variables. However, distribution was not 
illustrated. This will be done below. 



2.3 Distributed Components 

In order to illustrate how Community can handle distribution, consider the situation 
in which a cart can move in two different modes: slow and fast. More specifically, by 
default, a cart will move in fast mode. However, control points may be placed dy- 
namically along the track to slow down the cart: when the cart comes in the proximity 
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of a control point, it changes to slow mode and, before it leaves the restricted area, it 
goes back to fast mode. 

design Controlled Located Cart is 
outloc pos : Log 
inloc cpoint:Loc 
in next: Log 

prv busy@pos, in@cpoint : bool , dest@pos : Loc , mode@pos : [slow, fast] 
do move [pos] @pos : 

-■busyApos?^dest , false —> pos : =controlled (mode , pos) 

D prv enter [mode , in] 

@pos : true —> mode : =slow 
©cpoint: -lin — >in:=true 
D prv leave [mode, in] 

@pos : true — >mode:=fast 
Ocpoint : in — >in:=false 

D dock [busy] @pos : -■busyApos=dest, false — >busy:=true 

D undock [busy, dest] @pos : 

busyApos=dest , false — > busy : =f alse || dest:=next 

This design introduces a new location cpoint accounting for a control point; this 
location is declared to be input because we are leaving to the environment to 
(re)distribute the control points along the track. However, the position pos of the cart 
has now become output because it became under the control of the extended compo- 
nent (subsystem). 

A private channel in is located at the control point to indicate when a cart enters its 
proximity, which is controlled by the action enter. This action is distributed between 
the control point, where it updates in, and the cart, where it changes the mode to slow. 
The action leave operates the other way around. Both actions are declared to be pri- 
vate and their components are designed with a fully determined enabling condition 
because their execution is completely under the control of the component. 

The execution of a distributed action requires that the locations involved be “in- 
touch” so that one can ensure that they are executed as a single transaction. For in- 
stance, the physical links that support communication between the positions of the 
space of mobility (e.g. wired networks, or wireless communications through infrared 
or radio links) may be subject to failures or interruptions, making communication 
temporarily impossible. Formally, we rely on a set bt(l) for every location I that, at 
any given moment of time, consists of the locations that are “in touch” with 1 . Hence, 
for any action g and any locations l;,l2 to which it is distributed, g can only be exe- 
cuted if lj&t(l2) and l2&t(lj). In the case of the cart, this means that enter and 
leave actions can only take place when the cart is in the proximity of the control point. 

Notice that the action move is now making explicit that the next position is calcu- 
lated from the current one taking the mode into account. The function controlled that 
is being used will need to be defined, at specification time, on the representation cho- 
sen for the tracks. However, because move implies calculating a new position, an 
important condition applies: it can only be executed if the new position can be 
reached from the current one. 

Typically, the space of mobility has some structure, which can be given by walls 
and doors, barriers erected in communication networks by system administrators, or 
the simple fact that not every position of the space has a host where code can be exe- 
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cuted. This structure can change over time. Hence, it is not realistic to imagine that 
entities can migrate from any point to any point at any time without restrictions. 

Formally, we rely, for every location I, on a set reach(l) consisting, at any given in- 
stant of time, of the locations that can be reached from 1. Hence, for any located ac- 
tion g@l, if a location Ij can be affected by the execution of g@Z, then the new value 
of Ij must be a position reachable from 1. In the case of the cart, this means that move 
can only be executed if controlled returns a position that is reachable from the current 
one - e.g. no other cart is in between. 

Simpler modes of the movement of the cart could be envisioned, for instance 

design Step Located Cart is 
outloc pos :Loc 
in next: Log 

prv busy@pos ;bool , dest@pos;Loc 

do move [pos] @pos : -'busyApos?sdest , false — > pos : =inc (pos ) 

D dock [busy] @pos : -■busyApos=dest , false — >busy:=true 

D undock [busy , dest] @pos : 

busyApos=dest , false — > busy : =f alse || dest:=next 

In this case, we are relying on a simpler increment function on locations that leads 
the cart step by step through a path of a pre-established graph. The function itself can 
define the graph. For instance, by defining Loc as nat^, two different alternative 
graphs are: 




2.4 Formal Semantics 

In this section, we provide a summary of the mathematical semantics of Community 
designs. More details can be found in [9,13]. 

We start by mentioning that designs in Community are defined over a collection of 
data types that are used for structuring the data that the channels transmit and define 
the operations that perform the computations that are required. Hence, the choice of 
data types determines, essentially, the nature of the elementary computations that can 
be performed locally by the components, which are abstracted as operations on data 
elements. For simplicity, we assume a fixed collection of data types, i.e. we shall not 
discuss the process of data refinement that needs to be involved when mapping de- 
signs and their interconnections to the platforms that support computations and coor- 
dination. In order to remain independent of any specific language for the definition of 
these data types, we take them in the form of a first-order algebraic specification. 
That is to say, we assume a data signature E=<S,f2>, where S is a set (of sorts) and Q 
is a 5*xS-indexed family of sets (of operations), to be given together with a collection 
0 of first-order sentences specifying the functionality of the operations. We refer to 
this data type specification by 0. 




Community on the Move: Architectures for Distribution and Mobility 



185 



A Community design is a pair <0,A> where: 

— 0, the signature of the design, is a tuple <L,X, F,tv,ta,D,A> where 

• L is a finite pointed set, we use X to designate its point; 

• X is an S-indexed family of mutually disjoint finite sets; 

• Pis a finite set; 

• tv; XUL—^{out,in,prvl is a total function s.t. tv(X)=out; for ACXUL, we 
shall use out(A) to denote the set (a£ A:tv(a)=out} (and similarly for 
in(A) and prv(A)) and local(A) to denote out(A) Uprv(A); 

• ta; P—^(sh,prv} is a total function, 

• A; XUP—Xf is a total function s.t. Z£A(g), for every gEXUP and 
A(i)={/L},for every iSn(X); 

• D; is a total function. 

— A, the body of the design, is a tuple <R,L,U> where; 

• R assigns to every action g£P and lEA(g), a proposition over 
XULUDig)’ s.t. \-R(g@X)=>A,^^^f(g@l); 

• L and U assign a proposition over XUL to every action g£P and l£A(g) 
s.t. \-L(g@/L)z}A,^^^^^L(g@l) and \~ U(g@X)=>A,^^^p(g@l). 

It is important to notice that the conditions on the guarded commands associated 
with located actions of the form g@/l justify why, as mentioned before, the reference 
to g@X can be omitted in some situations. When the command associated with g has 
been fully distributed over a given set of locations (i.e., R(g@Z)^Ai^^^^fi(g@l), 
L(g@X)<^A,^^^f(g@l) and U(g@X)<^A,^^^p(g@l)), the guard of g@X and its ef- 
fects have been accounted for and, hence, g@A can be omitted because it does not 
provide any additional information. 

In order to define the behaviour of a program F, we have to fix, first of all, an al- 
gebra Zl for the data types in X. The sets Wj define the possible values of the each data 
sort s in X. In particular, the set ?4oc defines the positions of the space of mobility for 
the situation at hand. In addition, we also have to fix a function rs:Q—^N. This func- 
tion establishes the level of resources required for the computation of each operation 
in Q. In order to define the behaviour of P, we also need a model of the “world” 
where P is placed to run which should capture that this world may be continuously 
changing. In fact, we only need to know the properties and behaviour of the part of 
the environment that may affect the program execution - its context. 

In Community, the context that a component perceives is determined by its current 
position. A context is defined by a set Cxt of pairs obs;type, where obs is simply an 
identifier and type is a data sort. Cxt models the notion of context that is considered 
to be suitable for the situation at hand. Each obs represents an observable that can be 
used for designing the system, and type defines the type of its values. As a conse- 
quence, obs can be used in Community designs as any other term of sort type. The 
only requirement that we make is for three special observables - rssv;natx2^, bt:2‘^’^ 
and reach;2‘^’^ - to be distinguished. 

The purpose of rssv;natX2^ is to represent the resources and services that are avail- 
able for computation. The first component of rssv quantifies the resources available. 
It may be defined as a function of more specific observables in Cxt, for instance, the 
remaining lifetime of a battery or the amount of memory available. In this way, it is 
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possible to model the fact that the same resources may affect different applications in 
different ways. The second component of rssv represents the services available and it 
is taken as a part of the data signature X This is because, as we have seen in the pre- 
vious sections, the services that perform the computations are abstracted as operations 
on data elements. In this paper, we will not illustrate this particular aspect of Com- 
munity; see [13] instead. 

The intuition behind bt:2‘^’^ and reach:2‘^’^ is even simpler: both represent the set of 
locations that are accessible. The former represents the locations that can be reached 
through communication while the latter concerns reachability through movement. We 
have already motivated the use of these relations in section 2.3. 

We consider that such models are Cxt-indexed sets {^„hs:typJobs:typeECxt of infinite 
sequences of functions over Upoc- Each !M„bs:type is an infinite sequence of functions 
that provide the value of the observable obs at every position of the space, at a par- 
ticular instant of time. For the special observables rssv:natx2^, bt:2‘^’^ and reach:2‘^’^, 
these functions are constrained as follows. 

Every function in and maps a position m into a set of positions that must 
include m. Intuitively, this means that we require that “be in touch” and “reachabil- 
ity” are reflexive relations. Furthermore, for the observable bt, only the sets of posi- 
tions that include the special position admissible values. This condition estab- 

lishes part of the special role played by at every position of the space, the position 
_/.« is always “in touch”. In addition, we require that every function in maps _/.« 
to Loc. In this way, any entity located at _/.« can communicate with any other entity in 
a location-transparent manner and vice-versa. 

The position ±u is also special because it supports context-transparent computa- 
tion, i.e. a computation that takes place at _/.« is not subject to any kind of restriction. 
This is achieved by requiring that every function in assigns the value {+<>o,X) to 
the position ±u- In other words, the computational resources available at _/.« are 
unlimited and all the services are available. 

The behaviour of a program running in the context of {^hs.typelobs. typeECxt is ns fol- 
lows. The conditions under which a distributed action g can be executed at time i are 
the following: 

1. For every [I 2 ]' £Mb,'([liI) and [Ijf GMb,‘([l 2 l))'- the execution of g 

involves the synchronisation of its local actions and, hence, their positions have 
to be mutually in touch. 

2. For every lGA(g), g@l can be executed, i.e., 

i. If !M^^J[l]‘)=(n,X’) then, for every operation symbol f used in the guarded 
command associated to g@l, f is an operation in Z’ and rs(f)<n: in order to 
perform the computations that are required, the services and the level of re- 
sources needed for these computations have to be available. 

ii. For every local channel x used in the guarded command associated to g@l, if 
X is located at /, (x@l,), then [ljElMb,'([lf): the execution of the guarded 
command associated with g@l requires that every channel in its frame can be 
accessed from its current position and, hence, I has to be in touch with the lo- 
cations of each of these channels. 
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hi. For every location l,GD(g), [F(g@l,ljf '([IJ)- if a location Ij can be 

effected by the execution of g@ I, then the new value of /; must be a position 
reachable from the current one. 
iv. The local guard L(g@l)( =U(g@l)) evaluates to true. 

By [e f we denote the value of the expression e at time i. It is important to notice 
that, because observables can be used in programs as terms, the evaluation of an ex- 
pression e at time i may also depend on the model of Cxt. 

Given this, the execution of the action consists of the transactional execution of its 
guarded commands at their locations, which requires the atomic execution of the 
multiple assignments. Private actions are subject to a fairness requirement: if infi- 
nitely often enabled, they are guaranteed to be selected infinitely often. 



3 Architectural Concerns in Community 

Section 2 illustrated several of the primitives provided in Community for the design 
of distributed and mobile components. It did so through an incremental process of 
addition of detail to an initial, abstract account of the behaviour of a cart. CommmU- 
nity does not prescribe any specific method of incremental development. Instead, it 
provides the ability for different concerns to be modelled independently and super- 
posed dynamically over the configuration of a system to account for new design deci- 
sions. 

For instance, if we consider the addition of the distribution/mobility aspects in sec- 
tion 2.3, it is clear that the behaviour of the cart at the stations is not concerned. 
Moreover, it should be possible to capture these aspects as an architectural element 
(connector) that is being plugged to control the movement of cart. Changing from the 
fast/slow control to the step-by-step mode should be just a matter of unplugging a 
connector and plugging a new one; it should not require the cart to be re-designed or 
re-implemented. 

Another example can be given as follows. Consider that we now need to monitor 
the number of times a cart docks at a station. It seems clear that we should be able 
to: 

• Address this issue independently of the way the movement of the cart is being 
controlled, i.e. regardless of whether we are monitoring a step or a controlled lo- 
cated cart. 

• Separate the “logic” of monitoring from the location in which the data that is 
required is provided, i.e. address interaction separately from the location as- 
pects. 

In this section, we address these issues in two steps. First, we illustrate how con- 
nectors can be externalised from components. Then, we address the separate model- 
ling of coordination and distribution. 
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3.1 Externalising the Connector 

Consider again the controlled located cart and the way it was obtained from the lo- 
cated cart. The following design attempts at externalising the extension that was 
performed. 

design Mode controller is 
inloc mine: Log 
outloc theirs :Loc 

prv in@mine :bool , mode@theirs : [slow, fast] 

do control [theirs] ©theirs ; true —> theirs : =controlled (mode, theirs) 

D prv enter [mode , in] 

©theirs: true ^mode:=slow 
©mine: -lin ^in:=true 
D prv leave [mode , in] 

©theirs: true ^mode:=fast 
©mine: in ^in:=false 

This design contains more than just what was added to the located cart; it repeats 
the elements that are necessary for this extension to be autonomous as a design. This 
is why it includes both the location of the cart and the action of the cart that is being 
controlled. Notice, however, that the action control is always enabled; the idea, as 
detailed below, is that restrictions on its occurrence are left to the component being 
controlled. 

We deliberately changed the names of some of the design elements to highlight the 
fact that we want this mode controller to exist, as a design, independently of the lo- 
cated cart. However, this renaming is not necessary because it is automatically en- 
forced in Category Theory [8], which is the mathematical framework in which we 
give semantics to our interconnection mechanisms. As far as we are concerned, this 
mode controller could even pre-exist the located cart as part of a library of connectors 
that a software architect uses for designing a system. What we need to say is how it 
can be applied to a component like a located car. 

Community supports the design of interactions through configurations; these are 
diagrams that exhibit interconnections between designs. For instance, a located cart 
under the control of a mode controller is specified by the following configuration: 




In configuration diagrams, components only depict their public elements. The 
lines connect locations, channels and actions. In contrast with what happens with 
most architectural description languages, “boxes and lines” in Community have a 
mathematical semantics. As explained in section 3.2, configuration diagrams are 
diagrams in a category of Community designs whose morphisms capture notions of 
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superposition that are typical in parallel program design [6,10,12]. The semantics of 
such a diagram is given by its colimit [8], which can be informally explained as the 
design of the system viewed as a single, distributed component: 

• Connected locations are amalgamated; input locations can be connected with in- 
put connections, in which case their amalgamation is an input location, our with 
output locations, in which case their amalgamation is an output location; output 
locations cannot be connected with output locations. 

• The same rule applies to channels; only channels carrying the same type of data 
can be connected. 

• Connected actions give rise to joint distributed actions; every set {g,,...,gj of ac- 
tions that are synchronised is represented by a single action gJI-..Hg„ whose occur- 
rence captures the joint execution of the actions in the set. The transformations 
performed by the joint action are distributed over the locations of the synchro- 
nised actions. Each located action gjj...jjgj^l is specified by the conjunction of 
the specifications of the local effects of each of the synchronised actions that is 
distributed over /, and the guards of joint actions are also obtained through the 
conjunction of the guards specified by the components. 

We must call attention to the fact that elements (locations, channels and actions) 
that have the same name in different designs but are not connected need to be re- 
named. This is because there can be no implicit interconnection between designs 
resulting from accidental naming of locations, channels or actions. Any name binding 
needs to be made explicit through a line as illustrated. 

The design that we have just described is itself obtained only up to renaming; the 
actual choice of names for locations, channels, and actions does not really matter as 
long as all the interconnections are respected and no additional interconnections are 
introduced. Hence, in the case of the cart, what we obtain from the configuration 
above is a specification of the controlled located cart as given in section 2.3. Notice 
in particular that the result of synchronising the action 

move [pos] @pos : -ibusyApos^^dest , false — > true 
of located cart, and the action 

control [theirs] ©theirs : true ^ theirs : =controlled (mode , theirs ) 
of mode controller is, after the amalgamation of the locations, 

move [pos] ©pos : -ibusyApos?^:dest , false —> pos : =controlled (mode , pos) 

This is because the semantics of the composition is given by the conjunction of the 
guards and of the effects of the component actions. 

Summarising, we have expressed the behaviour of the controlled located cart as re- 
sulting from a configuration in which the located cart is connected to a component 
that controls its movement. The advantage of this representation is that, in order to 
change to a step-by-step control, we just need to replace the mode controller by an- 
other connector, namely 
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design Step controller is 
outloc theirs ;Loc 

do control [theirs] ©theirs ; true —> theirs : =inc (theirs) 
In this case, the required configuration is 




3.2 Semantics of Interconnection 

As already mentioned, the semantics of interconnection and configuration in Com- 
munity is based on Category Theory [8]. In this section, we will only provide the 
basic ingredients of this semantics. More details are available in [9,13]. 

We call a morphism o: Pi~^P 2 of Community designs a triple consisting of a to- 
tal function (Teh-' Xj—^X 2 , a partial mapping Oac: P' 2 ~^^i ^^d a total function 
(Ti^: Lj—>L 2 that maps the designated location of Pj to that of P 2 , satisfying: 

1. for every xEXj: 

(a) sort2((7ch(x))=sort](x); 

(b) if x&ut(Xj) then c7i.h(x)&ut(X2); 

(c) if x£prv(Xj) then Gchix) £prv{X 2 ); 

(d) if xGn(Xj) then (T^f^(x) £out(X 2 ) Uin(X 2 ). 

2. for every g s.t. (7afg)is defined: 

(a) ifg £sh( r' 2 ) then (^ac(g)^sh(r,); 

(b) ifg£prv(r 2 ) then aacig)Eprv(r,). 

3. for every xQCjand lELj 
(^) 

(f) if l£out(Lj) then aifl)£out(L 2 ); 

(g) (^ic(^i(x))£dL2(a,h(x)). 

4 . for every g s. t. g ) is defined: 

(c) (J,fA,{(7jg)))CA2(g). 

5. for every x£local(XjULj), (j^^istotalonD 2 ( 0 'ch(x))and 
(^ac(D 2 ( (Jjx)))CDi(x). 

6. for every g^r 2 s.t. (7^^ g) is defined and I ^Afa^fg)): 

(a) cfDf Gad g))CD 2 ( g); 

(b) 0\-R2(g@ (Tif l))=>gi R,(ajg)@l»; 

(c) 0 \-L 2 (g@aifl))=>giL,( ajg)@l)); 

(d) 0\-U2(g@(Tifl))z)g(U,(aJg)@l)). 

By |— we mean validity in the first-order sense taken over the axiomatisation O 
of the underlying data types. These morphisms define a category MDSG. 
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Configuration diagrams define diagrams in this category, i.e. graphs whose nodes 
are labelled with Community designs as defined in section 2.4, and arrows are la- 
belled with morphisms as defined above. Colimits of such diagrams define the se- 
mantics of configurations. 



3.3 Separating Coordination and Distribution 

Consider now the situation described at the beginning of this section: assume that we 
want to monitor how many times a cart has docked at a station. Intuitively, we should 
be able to start by putting in place just the mechanisms that coordinate the interaction 
between the cart and the monitor, which should not depend on the location and mobil- 
ity aspects of the cart. 

The interaction aspects of the monitor can be resumed to a counting function and 
designed as follows: 

design Counter is 

out count :nat 

do inc [count] : true ^ count : =count+l 

D reset [count] : true ^ count ;=0 

The counter can be connected to the original design of the cart because their inter- 
action does not involve mobility explicitly: 




The semantics of the configuration is given by the following design: 

design Monitored cart is 
prv busy: bool 

out count mat 

do move!] : -ibusy, false — > true 

D dock [busy , count] : -ibusy, false — >busy:=true || count := count +1 

D undock [busy] : busy, false — > busy : =f alse 

D reset [count] : true — > count :=0 

D move&reset [count] : -ibusy, false — > count :=0 

D undock&reset [busy , count] : busy, false — > busy : =f alse || count :=0 

Notice that the synchronisations of reset with move and undock are automatically 
added! This is because there is no reason to prevent the counter from being reset 
while the cart is moving or undocking. Should such synchronisations be undesirable, 
one would have to configure the system in a way that prevents them; the default se- 
mantics is of maximum parallelism. It is important to stress that this complex design 
is just providing the semantics of the configuration; it is the configuration that one 
should use to develop and evolve the system, not its semantics! In order to simplify 
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the presentation, we shall omit these synchronisations in the examples below and 
replace them by ‘ . . . ’ . 

This interconnection can be extended to the located cart because the designs Cart 
and Located Cart are related by a morphism as defined in 3.2. Indeed, because mor- 
phisms preserve locations, channels and actions, the interconnection propagates from 
the source to the target of the morphism: 




Once again, details on the semantics of this propagation of interconnections can be 
found in [13]. This semantics is based on the fact that, as explained in section 2.4, 
every design involves the implicit location Z. 

design Monitored Located cart is 
outloc pos :Loc 
in next:Loc 
out count@A.:nat 

prv busyOpos : bool , dest@pos:Loc 

do move [pos] @pos ; ->busyApos7^dest , false ^ true 
D dock [busy , count] 

@pos : -<busyApos=dest , false ^busy:=true 
@X: -ibusyApos=dest , false ^ busy;=true || count : =count+l 
D undock [busy , dest] @pos : 

busyApos=dest , false ^busy:=false || dest:=next 
D reset [count] : true ^ count :=0 

Decisions on the location of the counter can now be made independently of those 
made for the cart. A “minimal” decision is to consider that the location and mobility 
of the counter is left to the environment: 

design Counter* is 
inloc where :Loc 
out count@where : nat 

do inc [count] ©where : true —> count : =count+l 
D reset [count] ©where : true —> count :=0 

If one wants to place the counter in the cart, then the following configuration 
should be used: 
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design Monitored co-Located cart is 
inloc pos:Loc 

in next : Loc 

out count@pos : nat 

prv busy@pos : bool , dest@pos:Loc 

do move [pos] @pos : -ibusyApos?^:dest , false — > true 
D dock [busy , count] @pos : 

->busyApos=dest , false — >busy:=true || count : =count+l 
D undock [busy . dest] @pos : 

busyApos=dest , false — > busy : =f alse || dest:=next 
D reset [count] @pos : true ^ count :=0 



Notice that the dock action is no longer distributed and combines the actions of the 
cart and the counter. 

If one wants to place the counter at some fixed location, the following connector 
can be used: 

design Fixed is 
outloc stay: Loc 



Notice that, because no actions are provided for changing the location of Fixed, it 
cannot be moved! 




design Fixed Monitored Located cart is 
outloc stay: Loc 
inloc pos : Loc 
in next : Loc 
out count@stay : nat 
prv busy@pos : bool , dest@pos:Loc 

do move [pos] @pos : -ibusyApos^^dest , false — > true 
D dock [busy , count] 

@pos: ->busyApos=dest , false — >busy:=true 
©stay: true —> count : =count+l 
D undock [busy , dest] ©pos : 

busyApos=dest , false — > busy : =f alse || dest:=next 
D reset [count] ©stay : true ^ count :=0 



We can now put together our system by combining these different connectors, for 
instance a cart monitored by a fixed counter and step controller: 
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The ability to externalise connectors and address coordination and distribution in a 
separate way is what supports a true compositional approach to development and 
evolution: we can plug-in and plug-out the connectors that address the different con- 
cerns without having to redesign the system at the level of its code. Hence, it is pos- 
sible for changes to be performed immediately at the configuration level, without 
having to interfere with the lower levels of design. 



4 Conclusions and Further Work 

This paper presented, around a typical example - a luggage handling system, how 
Community is being extended with primitives that support the modelling of distribu- 
tion and mobility aspects at an architectural level. This extension is being pursued 
within the IST-2001-32747 ¥xo]ecl AGILE - Architectures for Mobility with two main 
goals in mind: 

• To provide support for the description of the mobility aspects of systems in a way 
that is completely separated from the computational and coordination concerns. 

• To be based on proper abstractions for modelling the part of the run-time envi- 
ronment that may affect their behaviour, what is often referred as context. 

This paper focused essentially on the first goal. We showed how a new class of ar- 
chitectural connectors can be defined that externalise patterns and policies related to 
the locations in which components perform computations and the network topology 
that supports coordination. Such connectors can be superposed over location- 
transparent models of components and connectors as a means of addressing the mo- 
bility-based aspects that reflect the properties of the operational and communication 
infrastructure without having to redesign the other dimensions. 

In this respect, our work goes one step beyond what can be found in the literature 
that addresses the formalisation of software architectures, e.g. [1]. In all the ap- 
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proaches that we know, including those around Mobile Unity [17,18], the mobility 
dimension is not taken as a separate and first-class aspect. 

Further work is in progress in several directions. 

On the one hand, we are using these results on Community to make available this 
level of architectural support in modelling languages like the UML. The aim is to 
extend the set of coordination-based semantic primitives that we developed in the past 
[2] with similar ones for distribution and mobility [4]. At the same time, we are relat- 
ing architectural design in Community with extensions of process languages like 
KLAIM [5] that can handle distribution and mobility at a lower level of abstraction. 

On the other hand, and towards the second goal mentioned above, we are further 
exploring the notion of context that we only briefly mentioned in section 2.4. Con- 
texts usually model these different types of resources as well as other kinds of exter- 
nal factors, from the screen size of a device to the power left on a battery. Given that 
different kinds of applications typically require different notions of context, it is im- 
portant that formalisms for designing mobile systems consider contexts as first-class 
design entities and support their explicit modelling. If a specific notion of context is 
assumed as, for instance, in Ambients [7], the encoding of a different notion of con- 
text can be cumbersome and entangled with other aspects, if at all possible. By ex- 
tending Community with the explicit modelling of a notion of context, we hope to 
make it possible for such aspects to be progressively refined through the addition of 
detail, without interfering with the parts of the system already designed. 



Acknowledgements 

This work was partially supported through the IST-2001-32747 Project AGILE - 
Architectures for Mobility. We wish to thank our partners for much useful feedback. 



References 

1. R. Allen and D.Garlan, “A Formal Basis for Architectural Connectors”, ACM TOSEM 6(3), 
213-249, 1997. 

2. L.F.Andrade and J.L.Fiadeiro, “Architecture Based Evolution of Software Systems”, in 
M.Bernardo and P.Inverardi (eds). Formal Methods for Software Architectures, LNCS 
2804, 148-181, Springer Verlag 2003. 

3. L.F.Andrade, J.L.Fiadeiro, A.Lopes and M.Wermelinger, “Architectural Techniques for 
Evolving Control Systems”, in G.Tarnai and E.Schnieder (eds). Formal Methods for Rail- 
way Operation and Control Systems, 61-70, L’Harmattan Press 2003 

4. N.Aoumeur, J.L.Eiadeiro and C. Oliveira, “Towards an Architectural Approach to Loca- 
tion-Aware Business Processes”, in Proc. 13th IEEE International Workshops on Enabling 
Technologies: Infrastructures for Collaborative Enterprises (WETICE-2004), IEEE Com- 
puter Society Press 2004. 

5. L. Bettini, M. Loreti, and R. Pugliese “An Infrastructure Language for Open Nets”, in 
Proceedings of the 2002 ACM Symposium on Applied Computing, 373-377, ACM 2002 

6. K.Chandy and J.Misra, Parallel Program Design - A Foundation, Addison-Wesley 1988. 




196 



J.L. Fiadeiro and A. Lopes 



7. L.Cardelli and A.Gordon, “Mobile Ambients”, in Nivat (ed), FOSSACS’98, LNCS 1378, 
140-155, Springer-Verlag 1998. 

8. J.L.Fiadeiro, Categories for Software Engineering, Springer-Verlag 2004. 

9. J.L.Fiadeiro, A.Lopes and M.Wermelinger, “A Mathematical Semantics for Architectural 
Connectors”, in R.Backhouse and J.Gibhons (eds), Generic Programming, LNCS 2793, 
190-234, Springer-Verlag 2003. 

10. N.Francez and I.Forman, Interacting Processes, Addison-Wesley 1996. 

11. D.Gelemter and N.Carriero, “Coordination Languages and their Significance”, 
Communications ACM 35(2), 97-107, 1992. 

12. S.Katz, “A Superimposition Control Construct for Distributed Systems”, ACM TOPLAS 
15(2), 337-356, 1993. 

13. A.Lopes and J.L.Fiadeiro, “Adding Mobility to Software Architectures”, in A.Brogi and 
J.-M.Jacquet (eds), FOCLASA 2003 - Foundations of Coordination Languages and Soft- 
ware Architecture, Electronic Notes in Theoretical Computer Science. Elsevier Science, in 
print. 

14. A.Lopes, J.L.Eiadeiro and M.Wermelinger, “Architectural Primitives for Distribution and 
Mobility”, in Proc. SIGSOFT 2002/FSE-10, 41-50, ACM Press 2002. 

15. A.Lopes and J. L. Fiadeiro, “Using Explicit State to Describe Architectures”, in 
E.Astesiano (ed), FASE’99, LNCS 1577, 144-160, Springer-Verlag 1999. 

16. D.Perry and A.Wolf, “Foundations for the Study of Software Architectures”, ACM SIG- 
SOFT Software Engineering Notes 17(4), 40-52, 1992. 

17. G.Picco, G.-C.Roman and P.McCann, “Expressing Code Mobility in Mobile Unity”, in 
M.Jazayeri and H.Schauer (eds), Proc. 6th ESEC, LNCS 1301, 500-518, Springer-Verlag 
1998. 

18. G.-C.Roman, A.L.Murphy and G.P.Picco, “Coordination and Mobility”, in A.Omicini et al 
(eds). Coordination of Internet Designs: Models, Techniques, and Applications, 253-273, 
Springer-Verlag 2001. 

19. M.Wermelinger and J.Eiadeiro, “Connectors for Mobile Programs”, IEEE Transactions on 
Software Engineering 24(5), 331-341, 1998. 




TulaFale: A Security Tool for Web Services 



Karthikeyan Bhargavan, Cedric Fournet, 
Andrew D. Gordon, and Riccardo Pucella 

Microsoft Research 



Abstract. Web services security specifications are typically expressed 
as a mixture of XML schemas, example messages, and narrative expla- 
nations. We propose a new specification language for writing comple- 
mentary machine-checkable descriptions of SOAP-based security pro- 
tocols and their properties. Our TulaFale language is based on the pi 
calculus (for writing collections of SOAP processors running in paral- 
lel), plus XML syntax (to express SOAP messaging), logical predicates 
(to construct and filter SOAP messages), and correspondence assertions 
(to specify authentication goals of protocols). Our implementation com- 
piles TulaFale into the applied pi calculus, and then runs Blanchet’s 
resolution-based protocol verifier. Hence, we can automatically verify 
authentication properties of SOAP protocols. 



1 Verifying Web Services Security 

Web services are a wide-area distributed systems technology, based on asyn- 
chronous exchanges of XML messages conforming to the SOAP message for- 
mat [BEK+00, W3C03]. The WS-Security standard [NKHBM04] describes how 
to sign and encrypt portions of SOAP messages, so as to achieve end-to-end 
security. This paper introduces TulaFale, a new language for defining and au- 
tomatically verifying models of SOAP-based cryptographic protocols, and illus- 
trates its usage for a typical request/response protocol: we sketch the protocol, 
describe potential attacks, and then give a detailed description of how to define 
and check the request and response messages in TulaFale. 

1.1 Web Services 

A basic motivation for web services is to support programmatic access to web 
data. The HTML returned by a typical website is a mixture of data and presen- 
tational markup, well suited for human browsing, but the presence of markup 
makes HTML a messy and brittle format for data processing. In contrast, the 
XML returned by a web service is just the data, with some clearly distinguished 
metadata, well suited for programmatic access. For example, search engines ex- 
port web services for programmatic web search, and e-commerce sites export 
web services to allow affiliated websites direct access to their databases. 

Generally, a broad range of applications for web services is emerging, from 
the well-established use of SOAP as a platform and vendor neutral middleware 
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within a single organisation, to the proposed use of SOAP for device-to-device 
interaction [S+04]. 

In the beginning, “SOAP” stood for “Simple Object Access Protocol”, and 
was intended to implement “RPC using XML over HTTP” [Win98, Win99, 
BoxOl]. HTTP facilitates interoperability between geographically distant ma- 
chines and between those in protection domains separated by corporate fire- 
walls that block many other transports. XML facilitates interoperability between 
different suppliers’ implementations, unlike various binary formats of previous 
RPC technologies. Still, web services technology should not be misconstrued 
as HTTP-specific RPC for distributed objects [Vog03]. HTTP is certainly at 
present the most common transport protocol, but the SOAP format is inde- 
pendent of HTTP, and some web services use other transports such as TCP 
or SMTP [SMWC03]. The design goals of SOAP/1.1 [BEK+00] explicitly pre- 
clude object-oriented features such as object activation and distributed garbage 
collection; by version 1.2 [W3C03], “SOAP” is a pure name, not an acronym. 
The primitive message pattern in SOAP is a single one-way message that may 
be processed by zero or more intermediaries between two end-points; RPC is a 
derived message pattern built from a request and a response. In brief, SOAP is 
not tied to objects, and web services are not tied to the web. Still, our running 
example is an RPC over HTTP, which still appears to be the common case. 

1.2 Securing Web Services with Cryptographic Protocols 

Web services specifications support SOAP-level security via a syntax for embed- 
ding cryptographic materials in SOAP messages. To meet their security goals, 
web services and their clients can construct and check security headers in mes- 
sages, according to the WS-Security format [IM02, NKHBM04]. WS-Security can 
provide message confidentiality and authentication independently of the under- 
lying transport, using, for instance, secure hash functions, shared-key encryp- 
tion, or public-key cryptography. WS-Security has several advantages compared 
to using a secure transport such as SSL, including scalability, flexibility, trans- 
parency to intermediaries such as firewalls, and support for non-repudiation. 
Significantly, though, WS-Security does not itself prescribe a particular security 
protocol: each application must determine its security goals, and process security 
headers accordingly. 

Web services may be vulnerable to many of the well-documented classes of 
attack on ordinary websites [SS02,HL03]. Moreover, unlike typical websites, web 
services relying on SOAP-based cryptographic protocols may additionally be 
vulnerable to a new class of XML rewriting attacks : a range of attacks in which an 
attacker may record, modify, replay, and redirect SOAP messages, but without 
breaking the underlying cryptographic algorithms. Flexibility comes at a price 
in terms of security, and it is surprisingly easy to misinterpret the guarantees 
actually obtained from processing security headers. XML is hence a new setting 
for an old problem going back to Needham and Schroeder’s pioneering work 
on authentication protocols; SOAP security protocols should be judged safe, 
or not, with respect to an attacker who is able to “interpose a computer on 
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all communication paths, and thus can alter or copy parts of messages, replay 
messages, or emit false material” [NS78]. XML rewriting attacks are included 
in the WS-I threat model [DHK+04]. We have found a variety of replay and 
impersonation attacks in practice. 

1.3 Formalisms and Tools for Cryptographic Protocols 

The use of formal methods to analyze cryptographic protocols and their vulner- 
abilities begin with work by Dolev and Yao [DY83]. In the past few years there 
has been intense research on the Dolev-Yao model, leading to the development 
of numerous formalisms and tools. 

TulaFale builds on the line of research using the pi calculus. The pi cal- 
culus [Mil99] is a general theory of interaction between concurrent processes. 
Several variants of the pi calculus, including spi [AG99], and a generalization, 
applied pi [AFOl], have been used to formalize and prove properties of cryp- 
tographic protocols. A range of compositional reasoning techniques is available 
for proving protocol properties, but proofs typically require human skill and de- 
termination. Recently, however, Blanche! [BlaOl, Bla02] has proposed a range 
of automatic techniques, embodied in his theorem prover ProVerif, for checking 
certain secrecy and authentication properties of the applied pi calculus. ProVerif 
works by compiling the pi calculus to Horn clauses and then running resolution- 
based algorithms. 

1.4 TulaFale: A Security Tool for Web Services 

TulaFale is a new scripting language for specifying SOAP security protocols, and 
verifying the absence of XML rewriting attacks: 

TulaFale = processes -I- XML -I- predicates -I- assertions 

The pi calculus is the core of TulaFale, and allows us to describe SOAP 
processors, such as clients and servers, as communicating processes. We extend 
the pi calculus with a syntax for XML plus symbolic cryptographic operations; 
hence, we can directly express SOAP messaging with WS-Security headers. We 
declaratively specify the construction and checking of SOAP messages using 
Prolog-style predicates; hence, we can describe the operational details of SOAP 
processing. Independently, we specify security goals using various assertions, 
such as correspondences for message authentication and correlation. 

It is important that TulaFale can express the detailed structure of XML sig- 
natures and encryption so as to catch low-level attacks on this structure, such 
as copying part of an XML signature into another; more abstract representa- 
tions of message formats, typical in the study of the Dolev-Yao model and used 
for instance in previous work on SOAP authentication protocols [GP03], are 
insensitive to such attacks. 

Our methodology when developing TulaFale has been to study particular 
web services implementations, and to develop TulaFale scripts modelling their 
security aspects. Our experiments have been based on the WSE development 
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Fig. 1. Modelling WS-Security protocols with TulaFale 

kit [Mic02], a particular implementation of WS-Security and related specifica- 
tions. We have implemented the running example protocol of this paper using 
WSE, and checked that the SOAP messages specified in our script faithfully 
reflect the SOAP messages observed in this implementation. For a discussion of 
the implementation of related protocols, including logs of SOAP messages, see 
the technical report version of an earlier paper [BFG04a]. 

Fig. 1 illustrates our methodology. On the left, we have the user-supplied 
code for implementing a web services protocol, such as the one of this paper, 
on top of the WSF library. On the right, we have the TulaFale script modelling 
the user-supplied code, together with some library predicates modelling opera- 
tions performed by WSF. Also on the right, we have the TulaFale tool, which 
compiles its input scripts into the pure applied pi calculus to be analyzed via 
ProVerif. 

TulaFale is a direct implementation of the pi calculus described in a pre- 
vious formal semantics of web services authentication [BFG04a]. The original 
contribution of this paper is to present a concrete language design, to report an 
implementation of automatic verification of assertions in TulaFale scripts using 
Blanchet’s ProVerif, and to develop a substantial example. 

Section 2 informally introduces a simple request /response protocol and its 
security goals: authentication and correlation of the two messages. Section 3 
presents TulaFale syntax for XML with symbolic cryptography and for pred- 
icates, and as a source of examples, explains a library of TulaFale predicates 
for constructing and checking SOAP messages. Section 4 describes predicates 
specific to the messages of our request/response protocol. Section 5 introduces 
processes and security assertions in TulaFale, and outlines their implementation 
via ProVerif. Section 6 describes processes and predicates specific to our proto- 
col, and shows how to verify its security goals. Finally, Section 7 concludes. 
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2 A Simple Request/Response Protocol 

We consider a simple SOAP-based request/response protocol, of the kind easily 
implemented using WSE to make an RPC to a web service. Our security goals 
are simply message authentication and correlation. To achieve these goals, the 
request includes a username token identifying a particular user and a signature 
token signed by a key derived from user’s password; conversely, the response in- 
cludes a signature token signed by the server’s public key. Moreover, to preserve 
the confidentiality of the user’s password from dictionary attacks, the username 
token in the request message is encrypted with the server’s public key. (For 
simplicity, we are not concerned here with any secrecy properties, such as confi- 
dentiality of the actual message bodies, and we do not model any authorization 
policies.) 

In the remainder of this section, we present a detailed but informal specifi- 
cation of our intended protocol, and consider some variations subject to XML 
rewriting attacks. Our protocol involves the following principals: 

— A single certification authority (CA) issuing X.509 public-key certificates for 
services, signed with the CA’s private key. 

— Two servers, each equipped with a public key certified by the CA and ex- 
porting an arbitrary number of web services. 

— Multiple clients, acting on behalf of human users. 

Trust between principals is modelled as a database associating passwords to 
authorized user names, accessible from clients and servers. Our threat model 
features an active attacker in control of the network, in possession of all public 
keys and user names, but not in possession of any of the following: 

(1) The private key of the CA. 

(2) The private key of any public key certified by the CA. 

(3) The password of any user in the database. 

The second and third points essentially rule out “insider attacks”; we are 
assuming that the clients, servers, and CA belong to a single close-knit institu- 
tion. It is easy to extend our model to study the impact of insider attacks, and 
indeed to allow more than two servers, but we omit the details in this expository 
example. 

Fig. 2 shows an intended run of the protocol between a client and server. 

— The principal Client(kr,U) acts on behalf of a user identified by U (an XML 
encoding of the username and password) . The parameter kr is the public key 
of the CA, needed by the client to check the validity of public key certificates. 

— The principal Server(sx,cert,S) implements a service identified by S (an XML 
encoding of a URL address, a SOAP action, and the subject name appearing 
on the service’s certificate). The parameter sx is the server’s private signing 
key, while cert is its public certificate. 

— The client sends a request message satisfying isMsgl(— ,U,S,idl,tl,bl), which 
we define later to mean the message has body bl, timestamp tl, and message 
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Fig. 2. An intended run of a client and server 

identifier idl, is addressed to a web service S, and has a <Security> header 
containing a token identifying U and encrypted with S’s public key, and a 
signature of S, idl, tl, and bl by U. 

— The server sends a response message satisfying isMsg2(— ,S,idl,id2,t2,b2), 
which we define later to mean the message has body b2, timestamp t2, 
and message identifier id2, is sent from S, and has a <Security> header 
containing S’s certificate cert and a signature of idl, id2, t2, and b2 by S. 

— The client and server enact begin- and end-events labelled Cl(U,S,idl,tl,bl) 
to record the data agreed after receipt of the first message. Similarly, the 
begin- and end-events labelled C2(U,S,idl,tl,bl,id2,t2,b2) record the data 
agreed after both messages are received. Each begin-event marks an intention 
to send data. Each end-event marks apparently successful agreement on data. 

The begin- and end-events define our authentication and correlation goals: for 
every end-event with a particular label, there is a preceding begin-event with the 
same label in any run of the system, even in the presence of an active attacker. 
Such goals are known as one-to-many correspondences [WL93] or non-injective 
agreements [Low97]. The Cl events specify authentication of the request, while 
the C2 events specify authentication of the response. By including data from the 
request, C2 events also specify correlation of the request and response. 

Like most message sequence notations. Fig. 2 simply illustrates a typical 
protocol run, and is not in itself an adequate specification. In Sections 4 and 6 we 
present a formal specification in TulaFale: we define the principals Client(kr,U) 
and Server(sx,cert,S) as parametric processes, and we define the checks isMsgl 
and isMsg2 as predicates on our model of XML with symbolic cryptography. The 
formal model clarifies the following points, which are left implicit in the figure: 
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Suppose a client does not sign the timestamp tl... 




Fig. 3. A replay attack 



— The client can arbitrarily choose which service S to call, and which data 
tl and bl to send. (In the formal model, we typically make such arbitrary 
choices by inputting the data from the opponent.) Conversely, the client 
must generate a fresh identifier idl for each request, or else it is impossible to 
correlate the responses from two simultaneous requests to the same service. 

— Similarly, the server can arbitrarily choose the response data id2, t2, and b2. 

On the other hand, our formal model does not directly address replay pro- 
tection. To rule out direct replays of correctly signed messages, we would need 
to specify that for each end-event there is a unique preceding begin-event with 
the same label. This is known as a one-to-one correspondence or injective agree- 
ment. In practice, we can protect against direct replays using a cache of recently 
received message identifiers and timestamps to ensure that no two messages are 
accepted with the same identifier and timestamp. Hence, if we can prove that 
the protocol establishes non-injective agreement on data including the identifiers 
and timestamps, then, given such replay protection, the protocol implementation 
also establishes injective agreement. 

We end this section by discussing some flawed variations of the protocol, 
corresponding to actual flaws we have encountered in user code for web services. 



— Suppose that the check isMsgI(— ,U,S,idl,tl,bl) only requires that S, idl, and 
bl, are signed by U, but not the timestamp tl. Replay protection based on 
the timestamp is now ineffective: the opponent can record a message with 
timestamp tl, wait until some time t2 when the timestamp has expired, 
and the message identifier idl is no longer being cached, rewrite the original 
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Suppose a client attaches the same identifier id 1 to two messages... 




Fig. 4. A failure of message correlation 



message with timestamp t2, and then replay the message. The resulting 
message satisfies isMsgl(— ,U,S,idl,t2,bl), since t2 does not need to be signed, 
and hence is accepted by the server. Fig. 3 shows the attack, and the resulting 
failure of correspondence Cl. 

— Suppose that a client re-uses the same message identifier in two different 
calls to a web service; the opponent can manipulate messages so that the 
client treats the response to the first call as if it were the response to the 
second call. Fig. 4 shows the attack. The client sends a first request with 
body bl and identifier idl. The opponent intercepts the response with body 
b2, and sends a SOAP fault back to the client. Subsequently, the client sends 
a second request with the same identifier idl as the first, and body bl’. The 
opponent can delete this request to prevent it reaching the service, and then 
replay the original response. The client now considers that b2 is the response 
to bl’, when in fact it is the response to bl, perhaps completely different. 
Formally, this is a failure of correspondence C2. 

— Suppose that the server does not include the request identifier idl in the 
signature on the response message. Then the opponent can mount a similar 
correlation attack, breaking C2 — we omit the details. 

We can easily adapt our TulaFale script to model these variations in the 
protocol. Our tool automatically and swiftly detects the errors, and returns 
descriptions of the messages sent during the attacks. These flaws in web services 
code are typical of errors in cryptographic protocols historically. The practical 
impact of these flaws is hard to assess, as they were found in preliminary code, 
before deployment. Still, it is prudent to eliminate these vulnerabilities, and tools 
such as TulaFale can systematically rule them out. 
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3 XML, Principals, and Cryptography in TulaFale 

This section introduces the term and predicate language of TulaFale, via a series 
of basic constructions needed for the example protocol of Section 2. Throughout 
the paper, for the sake of exposition, we elide some details of SOAP envelopes, 
such as certain headers and attributes, that are unconnected to security. 

3.1 XML Elements, Attributes, and Strings 

Here is a TulaFale term for a SOAP request, illustrating the format of the first 
message in our example protocol: 

<Envelope> 

<Header> 

<To>uri</> 

<Action>ac</> 

<MessageId>id</> 

<Security> 

<TimestampXCreated>"2004-03-19T09 : 46 : 32Z"</></> 
utok 

sig 

</> 

</> 

<Body Id="l">request</> 

</> 

Every SOAP message consists of an XML <Envelope> element, with two 
children: an optional <Header> and a mandatory <Body>. In this example, the 
header has four children, and the body has an Id-attribute, the literal string "1". 

We base TulaFale on a sorted (or typed) term algebra, built up from a set 
of function symbols and variables. The basic sorts for XML data include string 
(for string literals), att (for named attributes), and item (either an element or 
a string). Every element or attribute tag (such as Envelope or Id, for example) 
corresponds to a sorted function symbol in the underlying algebra. 

Although TulaFale syntax is close to the XML wire format, it is not identi- 
cal. We suppress all namespace information. As previously mentioned, we omit 
closing element tags; for example, we write </> instead of </Envelope>. Literal 
strings are always quoted, as in <Created>"2004-03-19T09 : 46 ; 32Z"</>. In the 
standard wire format, the double quotes would be omitted when a string is an 
element body. We use quotation to distinguish strings from term variables, such 
as the variables uri, ac, id, utok, sig, and request in the example above. 

3.2 Symbolic Cryptography 

In TulaFale, we represent cryptographic algorithms symbolically, as function 
symbols that act on a sort bytes of byte arrays. Each function is either a data con- 
structor, with no accompanying rewrite rule, or it is a destructor, equipped with 
a rewrite rule for testing or extracting data from an application of a constructor. 
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For example, encryption functions are constructors, and decryption functions are 
destructors. This approach, the basis of the Dolev-Yao model [DY83], assumes 
that the underlying cryptography is perfect, and can be faithfully reflected by ab- 
stract equational properties of the functions. It also abstracts some details, such 
as the lengths of strings and byte arrays. The TulaFale syntax for introducing 
constructors and destructors is based on the syntax used by ProVerif. 

For instance, we declare function symbols for RSA key generation, public-key 
encryption, and private-key decryption using the following TulaFale declarations: 

constructor pk(bytes):bytes. 
constructor rsa ( bytes, bytes) : bytes, 
destructor decrsa(bytes,bytes):bytes with 

decrsa(s,rsa(pk(s),b)) = b. 

The constructor pk represents the relationship between private and public 
keys (both byte arrays, of sort bytes); it takes a private key and returns the 
corresponding public key. There is no inverse or destructor, as we intend to 
represent a one-way function: given only pk(s) it is impossible to extract s. 

The constructor rsa(k,x) encrypts the data x:bytes under the public key k, 
producing an encrypted byte array. The destructor decrsa(s,e) uses the corre- 
sponding private key s to decrypt a byte array generated by rsa(pk(s),x). The 
destructor definition expresses the decryption operation as a rewrite rule: when 
an application of decrsa in a term matches the left-hand side of the rule, it may 
be replaced by the corresponding right-hand side. 

To declare RSA public-key signatures, we introduce another constructor 
rsashal(s,x) that produces a RSA signature of a cryptographic hash of data 
X under the private key s: 

constructor rsasha 1 ( bytes, bytes) : bytes, 
destructor checkrsashal(bytes, bytes, bytes):bytes with 
checkrsasha l(pk(s), X, rsasha l(s,x))=pk(s). 

To check the validity of a signature sig on x using a public key k, one can 
form the term checkrsashal(k,x,sig) and compare it to k. If k is a public key of 
the form pk(s) and sig is the result of signing x under the corresponding private 
key s, then this term rewrites to k. 

For the purposes of this paper, an X.509 certiflcate binds a key to a subject 
name by embedding a digital signature generated from the private key of some 
certifying authority (CA). We declare X.509 certificates as follows: 

constructor x509(bytes, string, string, bytes) bytes, 
destructor x509key( bytes) bytes with 
x509key(x509(s,u,a,k))=k. 
destructor x509user(bytes):string with 
x509user(x509(s,u,a,k))=u. 
destructor x509alg(bytes):string with 
x509alg(x509(s,u,a,k))=a. 
destructor checkx509(bytes,bytes):bytes with 
checkx509(x509(sr,u,a,k),pk(sr))=pk(sr). 
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The term x509(sr,u,a,k) represents a certificate that binds the subject name u 
to the public key k, for use with the signature algorithm a (typically rsashal). 
This certificate is signed by the CA with private key sr. Given such a certifi- 
cate, the destructors x509key, x509user, and x509alg extract the three public 
fields of the certificate. Much like checkrsashal for ordinary digital signatures, 
an additional destructor checkx509 can be used to check the authenticity of the 
embedded signature. 

3.3 XML Encryption and Decryption 

Next, we write logical predicates to construct and parse XML encrypted under 
some known RSA public key. A predicate is written using a Prolog-like syntax; it 
takes a tuple of terms and checks logical properties, such as whether two terms 
are equal or whether a term has a specific format. It is useful to think of some 
of the terms given to the predicate as inputs and the others as outputs. Under 
this interpretation, the predicate computes output terms that satisfy the logical 
properties by pattern-matching. 

The predicate mkEncryptedData takes a plaintext plain:item and an RSA 
public encryption key ek; bytes, and it generates an XML element encrypted 
containing the XML encoding of plain encrypted under ek. 

predicate mkEncryptedData (encrypted;item,plain:item,ek:bytes) 
cipher = rsa(ek,cl4n(plain)), 
encrypted = <EncryptedData> 

<CipherData> 

<CipherValue>base64(cipher)</></></>. 

The first binding in the predicate definition computes the encrypted byte 
array, cipher, using the rsa encryption function applied to the key ek and the 
plaintext plain. Since rsa is only defined over byte arrays, plaindtem is first 
converted to bytes using the (reversible) cl4n constructor. The second bind- 
ing generates an XML element (<EncryptedData>) containing the encrypted 
bytes. Since only strings or elements can be embedded into XML elements, the 
encrypted byte array, cipher, is first converted to a string using the (reversible) 
base64 constructor. 

In this paper, we use three transformation functions between sorts: cl4n 
(with inverse icl4n) transforms an item to a bytes, base64 (with inverse ibase64) 
transforms a bytes to a string, and utf8 (with inverse iutfS) transforms a string 
to a bytes. All three functions have specific meanings in the context of XML 
transformations, but we treat them simply as coercion functions between sorts. 

To process a given element, <Foo> say, we sometimes write distinct predicates 
on the sending side and on the receiving side of the protocol, respectively. By 
convention, to construct a <Foo> element, we write a predicate named mkFoo 
whose first parameter is the element being constructed; to parse and check it, 
we write a predicate named isFoo. 

For <EncryptedData>, for instance, the logical predicate isEncryptedData 
parses elements constructed by mkEncryptedData; it takes an element encrypted 
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and a decryption key dk;bytes and, if encrypted is an <EncryptedData> element 
with some plaintext encrypted under the corresponding encryption key pk(dk), 
it returns the plaintext as plain. 

predicate isEncryptedData (encrypted;item,plain;item,dk;bytes) : — 
encrypted = <EncryptedData> 

<CipherData> 

<CipherValue>base64(cipher)</></></>, 
cl4n(plain) = decrsa(dk, cipher). 

Abstractly, this predicate reverses the computations performed by mkEncryp- 
tedData. One difference, of course, is that while mkEncryptedData is passed the 
public encryption key ek, the isEncryptedData predicate is instead passed the 
private key, dk. The first line matches encrypted against a pattern representing 
the <EncryptedData> element, extracting the encrypted byte array, cipher. Re- 
lying on pattern-matching, the constructor base64 is implicitly inverted using its 
destructor ibase64. The second line decrypts cipher using the decryption key dk, 
and implicitly inverts cl4n using its destructor icl4n to compute plain. 

3.4 Services and X509 Security Tokens 

We now implement processing for the service identifiers used in Section 2. We 
identify each web service by a structure consisting of a <Service> element con- 
taining <To>, <Action>, and <Subject> elements. For message routing, the web 
service is identified by the HTTP URL uri where it is located and the name of 
the action ac to be invoked at the URL. (In SOAP, there may be several differ- 
ent actions available at the same uri.) The web service is then willing to accept 
any SOAP message with a <To> header containing uri and an <Action> header 
containing ac. Each service has a public key with which parts of requests may be 
encrypted, and parts of responses signed. The <Subject> element contains the 
subject name bound to the server’s public key by the X.509 certificate issued by 
the CA. For generality, we do not assume any relationship between the URL and 
subject name of a service, although in practice the subject name might contain 
the domain part of the URL. 

The logical predicate isService parses a service element to extract the <To> 
field as uri, the <Action> field as ac, and the <Subject> field as subj: 

predicate isService(S:item,uri:item,ac:item,subj:string) : — 

S = <ServiceXTo>uri</> <Action>ac</> <Subject>subj</></>. 

We also define predicates to parse X.509 certificates and to embed them in 
SOAP headers: 

predicate isX509Cert (xcert:bytes,kr:bytes,u:string,a:string,k:bytes) 
checkx509(xcert,kr) = kr, 
u = x509user(xcert), 
k = x509key(xcert), 
a = x509alg(xcert). 
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predicate isX509Token (tok;item,kr:bytes,u:string,a;string,k;bytes) : — 
tok = <BinarySecurityToken ValueType="X509v3">base64(xcert)</>, 
isX509Cert (xcert,kr,u,a,k). 

The predicate isX509Cert takes a byte array xcert containing an X.509 certifi- 
cate, checks that it has been issued by a certifying authority with public key kr, 
and extracts the user name u, its user public key k, and its signing algorithm a. 
In SOAP messages, certificates are carried in XML elements called security to- 
kens. The predicate isX509Token checks that an XML token element contains a 
valid X.509 certificate and extracts the relevant fields. 



3.5 Users and Username Security Tokens 

In our system descriptions, we identify each user by a <User> element that con- 
tains their username and password. The predicate isUser takes such an element, 
U, and extracts its embedded username u and password pwd. 

U = <User><Username>u</><Password>pwd</></>. 

In SOAP messages, the username is represented by a UsernameToken that 
contains the <Username> u, a freshly generated nonce n, and a timestamp t. The 
predicate isUserTokenKey takes such a token tok and extracts u, n, t, and then 
uses a user U for u to compute a key from pwd, n, and t. 

predicate isUserTokenKey (tok:item,U;item, mbytes, t:string,k:bytes) : — 
isUser(U,u,pwd), 
tok = <UsernameTokeii 0 _> 

<Username>u</> 

<Nonce>base64(n)</> 

<Created>t</></>, 
k = pshal(pwd,concat(n,utf8(t))). 

The first line parses U to extract the username u and password pwd. The 
second line parses tok to extract n and t, implicitly checking that the user- 
name u is the same. In TulaFale, lists of terms are written as tm\. . .trrim® tm 
with TO > 0, where the terms tmi, . . ., trura are the first to members of the list, 
and the optional term tm is the rest of the list. Here, the wildcard @ \_ of the 
<UsernameToken> element matches the entire list of attributes. The last line 
computes the key k by applying the cryptographic hash function pshal to pwd, 
n, and t (converted to bytes). (This formula for k is a slight simplification of the 
actual key derivation algorithm used by WSE.) The concat function returns the 
concatenation of two byte arrays. 



3.6 Polyadic Signatures 

An XML digital signature consists of a list of references to the elements being 
signed, together with a signature value that binds hashes of these elements using 
some signing secret. The signature value can be computed using several different 
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cryptographic algorithms; in our example protocol, we rely on hmacshal for user 
signatures and on rsashal for service signatures. 

The following predicates describe how to construct (mkSigVal) and check 
(isSigVal) the signature value sv of an XML element si, signed using the algo- 
rithm a with a key k. Each of these predicates is defined by a couple of clauses, 
representing symmetric and asymmetric signature algorithms. When a predicate 
is defined by multiple clauses, they are interpreted as a disjunction; that is, the 
predicate is satisfied if any one of its clauses is satisfied. 

predicate mkSigVal (sv:bytes,si;item,k:bytes,a:string) 
a = "hmacshal", sv = hmacshal(k,cl4n(si)). 

predicate isSigVal (sv;bytes,si:item,k:bytes,a;string) : — 
a = "hmacshal", sv = hmacshal(k,cl4n(si)). 

predicate mkSigVal (sv:bytes,si:item,k;bytes,a:string) 
a = "rsashal", sv = rsashal(k, cl4n(si)). 

predicate isSigVal (sv:bytes,si;item,p:bytes,a:string) : — 
a = "rsashal", p = checkrsashal(p,cl4n(si),sv). 

The first clause of mkSigVal takes an item si to be signed and a key k 
for the symmetric signing algorithm hmacshal, and generates the signature 
value sv. The first clause of isSigVal reverses this computation, taking sv, si, 
k, and a = "hmacshal" as input and checking that sv is a valid signature value 
of si under k. Since the algorithm is symmetric, the two clauses are identical. The 
second clause of mkSigVal computes the signature value using the asymmetric 
rsashal algorithm, and the corresponding clause of isSigVal checks this signa- 
ture value. In contrast to the symmetric case, the two clauses rely on different 
computations. 

A complete XML signature for a SOAP message contains both the signature 
value sv, as detailed above, and an explicit description of the message parts are 
used to generate si. Each signed item is represented by a <Reference> element. 

The predicate mkRef takes an item t and generates a <Reference> element r 
by embedding a shal hash of t, with appropriate sort conversions. Conversely, 
the predicate isRef checks that r is a <Ref erence> for t. 

predicate mkRef(t;item,r;item) : — 
r = <Reference> 

<0ther></> <0ther></> 

<DigestValue> base64(shal(cl4n(t))) </> </>. 

predicate isRef(t:item,r:item) 
r = <Reference> 

<DigestValue> base64(shal(cl4n(t))) </> </>. 
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(The XML constructed by mkRef abstracts some of the detail that is included in 
actual signatures, but that tends not to vary in practice; in particular, we include 
<0ther> elements instead of the standard <Transf orms> and <DigestMethod> 
elements. On the other hand, the <DigestValue> element is the part that de- 
pends on the subject of the signature, and that is crucial for security, and we 
model this element in detail.) 

More generally, the predicate mkRefs(ts,rs) constructs a list ts and from a 
list rs, such that their members are pairwise related by mkRef. Similarly, the 
predicate mkRefs(ts,rs) checks that two given lists are pairwise related by mkRef. 
We omit their definitions. 

A <SignedInf o> element is constructed from <Ref erence> elements for every 
signed element. A <Signature> element consists of a <SignedInf o> element si 
and a <SignatureValue> element containing sv. Finally, the following predicates 
define how signatures are constructed and checked. 

predicate mkSigInfo (si;item,a;string,ts;item) : — 
mkRefs(ts,rs), 
rs = <list>@ refs</>, 
si = <SignedInfo> 

<0ther></> <SignatureMethod Algorithm=a> </> 

@ refs </>. 

predicate isSigInfo (si:item,a:string,ts:item) 
si = <SignedInfo> 

_ <SignatureMethod Algor ithm=a> </> 

@ refs</>, 

rs = <list>@ refs</>, 
isRefs(ts.rs). 

predicate mkSignature (sig:item,a:string,k;bytes,ts:item) 
mkSiglnfo(si,a,ts), 
mkSigVal(sv,si,k,a), 

sig = <Signature> si <SignatureValue> base64(sv) </> </>. 

predicate isSignature (sig:item,a:string,k:bytes,ts;item) : — 
sig = <Signature> si <SignatureValue> base64(sv) </>@ _</>, 
isSiglnfo(si,a,ts), 
isSigVal(sv,si,k,a). 

The predicate mkSigInfo takes a list of items to be signed, embedded in a 
<list> element ts, and generates a list of references refs for them, embedded in 
a <list> element rs, which are then embedded into si. The predicate isSigInfo 
checks si has been correctly constructed from ts. 

The predicate mkSignature constructs si using mkSigInfo, generates the signa- 
ture value sv using mkSigVal, and puts them together in a <Signature> element 
called sig; isSignature checks that a signature sig has been correctly generated 
from a, k, and ts. 
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4 Modelling SOAP Envelopes for our Protocol 

Relying on the predicate definitions of Section 3, which reflect (parts of) the 
SOAP and WS-Security specifications but do not depend on the protocol, we 
now define custom “top-level” predicates to build and check Messages 1 and 2 
of our example protocol. 

4.1 Building and Checking Message 1 

Our goal Cl is to reach agreement on the data 
(U,S,idl,tl,bl) 
where 

U=<User><Username>u</xPassword>pwd</></> 

S=<Service><To>uri</><Action>ac</><Subject>subj</></> 

after receiving and successfully checking Message 1. To achieve this, the message 
includes a username token for U, encrypted with the public key of S (that is, one 
whose certificate has the subject name subj), and also includes a signature token, 
signing (elements containing) uri, ac, idl, tl, bl, and the encrypted username 
token, signed with the key derived from the username token. 

We begin with a predicate setting the structure of the first envelope: 

predicate envl(msgl;item,uri:item,ac:item,idl:string,tl:string, 
eutok:item,sigl:item,bl:item) : — 

msgl = 

<Envelope> 

<Header> 

<To>uri</> 

<Action>ac</> 

<MessageId>idl</> 

<Security> 

<TimestampXCreated>tl</></> 

eutok 

sigl</></> 

<Body>bl</></>. 

On the client side, we use a predicate mkMsgl to construct msgl as an output, 
given its other parameters as inputs: 

predicate mkMsgl(msgl:item,U:item,S:item,kr:bytes, cert: bytes, 
n:bytes,idl:string,tl:string,bl:item) : — 
isService(S,uri,ac,subj), 
isX509Cert(cert,kr,subj, "rsashal",ek), 
isUserTokenKey(utok,U,n,tl,sk), 
mkEncryptedData(eutok,utok,ek), 
mkSignature(sigl, "hmacshal " ,sk, 

<list> 
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<Body>bl</> 

<To>uri</> 

<Action>ac</> 

<MessageId>idl</> 

<Created>tl</> 

eutok</>), 

envl(msgl,uri,ac,idl,tl,eutok,sigl,bl). 

On the server side, with server certificate cert, associated private key sx, and 
expected user U, we use a predicate isMsgl to check the input msgl and produce 
S, idl, tl, and bl as outputs: 

predicate isMsgl( msgl :item,U: item, sx;bytes, cert: bytes, S: item, 
idl:string,tl:string,bl:item) : — 
envl(msgl,uri,ac,idl,tl,eutok,sigl,bl), 
isService(S,uri,ac,subj), 
isEncryptedData(eutok,utok,sx), 
isUserTokenKey(utok,U,n,tl,sk), 
isSignature(sigl, "hmacshal " ,sk, 

<list> 

<Body>bl</> 

<To>uri</> 

<Action>ac</> 

<MessageId>idl</> 

<Created>tl</> 

eutok</>). 



4.2 Building and Checking Message 2 

Our goal C2 is to reach agreement on the data 
(U,S,idl,tl,bl,id2,t2,b2) 
where 

U=<User><Username>u</xPassword>pwd</></> 

S=<Service><To>uri</><Action>ac</xSubject>subj</></> 

after successful receipt of Message 2, having already agreed on 

(U,S,idl,tl,bl) 

after receipt of Message 1. 

A simple implementation is to make sure that the client’s choice of idl in 
Message 1 is fresh and unpredictable, to include <relatesTo>idl</> in Mes- 
sage 2, and to embed this element in the signature to achieve correlation with 
the data sent in Message 1 . In more detail. Message 2 includes a certificate for S 
(that is, one with subject name subj) and a signature token, signing (elements 
containing) idl, id2, t2, and b2 and signed using the private key associated with 
S’s certificate. The structure of the second envelope is defined as follows: 
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predicate env2(msg2:item,uri:item,idl;string,id2:string, 
t2:string,cert:bytes,sig2:item,b2:item) 

msg2 = 

<Envelope> 

<Header> 

<From>uri</> 

<RelatesTo>idl</> 

<MessageId>id2</> 

<Security> 

<TimestampXCreated>t2</></> 

<BinarySecurityToken>base64(cert)</> 

sig2</></> 

<Body>b2</></>. 

A server uses the predicate mkMsg2 to construct msg2 as an output, given 
its other parameters as inputs (including the signing key) : 

predicate mkMsg2(msg2:item,sx:bytes,cert:bytes,S:item, 
idl:string,id2:string,t2:string,b2:item): — 
isService(S,uri,ac,subj), 
mkSignature(sig2,"rsash.al",sx, 

<list> 

<Body>b2</> 

<RelatesTo>idl</> 

<MessageId>id2</> 

<Created>t2</></>), 

env2(msg2,uri,idl,id2,t2,cert,sig2,b2). 

A client, given the CA’s public key kr, and awaiting a response from S to a 
message with unique identifier idl, uses the predicate isMsg2 to check its input 
msg2, and produce data id2, t2, and b2 as outputs. 

predicate isMsg2(msg2:item,S:item,kr:bytes, 

idl:string,id2:string,t2;string,b2:item) 
en v2(msg2, uri, idl, id2, t2, cert, sig2,b2), 
isService(S,uri,ac,subj), 
isX509Cert(cert,kr,subj, "rsashal",k), 
isSignature(sig2, "rsashal " ,k, 

<list> 

<Body>b2</> 

<RelatesTo>idl</> 

<MessageId>id2</> 

<Created>t2</></>). 




TulaFale: A Security Tool for Web Services 



215 



5 Processes and Assertions in TulaFale 

A TulaFale script defines a system to be a collection of concurrent processes 
that may compute internally, using terms and predicates, and may also commu- 
nicate by exchanging terms on named channels. The top-level process defined 
by a TulaFale script represents the behaviour of the principals making up the 
system — some clients and servers in our example. The attacker is modelled as an 
arbitrary process running alongside the system defined by the script, interacting 
with it via the public channels. The style of modelling cryptographic protocols, 
with an explicit given process representing the system and an implicit arbitrary 
process representing the attacker, originates with the spi calculus [AG99]. We 
refer to the principals coded explicitly as processes in the script as being compli- 
ant, in the sense they are constrained to follow the protocol being modelled, as 
opposed to the non-compliant principals represented implicitly by the attacker 
process, who are not so constrained. 

A TulaFale script consists of a sequence of declarations. We have seen already 
in Sections 3 and 4 many examples of Prolog-style declarations of clauses defining 
named predicates. This section describe three further kinds of declaration — 
for channels, correspondence assertions, and processes. Section 6 illustrate their 
usage in a script that models the system of Section 2. 

We describe TulaFale syntax in terms of several metavariables or nonter- 
minals: sort, term, and form range over the sorts, algebraic terms, and logical 
formulas, respectively, as introduced in Section 3; and ide ranges over alphanu- 
meric identifiers, used to name variables, predicates, channels, processes, and 
correspondence assertions. 

A declaration channel ide{sort\ sortn) introduces a channel, named ide, 

for exchanging n-tuples of terms with sorts sorti, . . ., sortn- As in the asyn- 
chronous pi calculus, channels are named, unordered queues of messages. By 
default, each channel is public, that is, the attacker may input or output mes- 
sages on the channel. The declaration may be preceded by the private keyword 
to prevent the attacker accessing the channel. Typically, SOAP channels are 
public, but channels used to represent shared secrets, such as passwords, are 
private. 

In TulaFale, as in some forms of the spi calculus, we embed correspondence 
assertions in our process language in order to state certain security properties 
enjoyed by compliant principals. 

A declaration correspondence ide(sort\ sortn) introduces a label, ide, 

for events represented by n-tuples of terms with sorts sort\, . . ., sortn- Each 
event is either a begin-event or an end-event; typically, a begin-event records an 
initiation of a session, and an end-event records the satisfactory completion of a 
session, from the compliant principals’ viewpoint. The process language includes 
constructs for logging begin- and end-events. The attacker cannot observe or 
generate events. We use correspondences to formalize the properties (Cl) and 
(C2) of Section 2. The declaration of a correspondence on ide specifies a security 
assertion: that in any run of the explicit system composed with an arbitrary 
implicit attacker, every end-event labelled ide logged by the system corresponds 
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to a previous begin-event logged by the system, also labelled ide, and with the 
same tuple of data. We name this property robust safety, following Gordon and 
Jeffrey [GJ03]. The implication of robust safety is that two compliant processes 
have reached agreement on the data, which typically include the contents of a 
sequence of one or more messages. 

A declaration process ide{idei'.sorti iden-sortn) — proc defines a para- 

metric process, with body the process proc, named ide, whose parameters idei, 
. . ., idcn have sorts sorti, . . ., sortn, respectively. 

Next, we describe the various kinds of TulaFale process. 

— A process out ide{tmi tm„); proc sends the tuple {tmi, . . ., on the 

ide channel, then runs proc. 

— A process in ide{ide\ zde„); proc blocks awaiting a tuple {tmi, . . ., trun) 

on the ide channel; if one arrives, the process behaves as proc, with its pa- 
rameters idci, . . ., idcn bound to tmi, ■ ■ •> tmn, respectively. 

— A process new zde:bytes; proc binds the variable ide to a fresh byte array, to 
model cryptographic key or nonce generation, for instance, then runs proc. 
Similarly, a process new zde:string; proc binds the variable ide to a fresh 
string, to model password generation, for instance, then runs as proc. 

— A process proci\proc 2 is a parallel composition of subprocesses proci and 
proc 2 ', they run in parallel, and may communicate on shared channels. 

— A process \proc is a parallel composition of an unbounded array of replicas 
of the process proc. 

— The process 0 does nothing. 

— A process let ide = tm\ proc binds the term tm to the variable ide, then runs 
proc. 

— A process filter form — > idci proc binds terms tmi, ■ • •, tmn to the 

variables idci, . . ., ide„ such that the formula form holds, then runs proc. 
(The terms tmi, • ■ tmn are computed by pattern-matching, as described 
in a previous paper [BFG04a].) 

— A process ide{tmi tmn), where ide corresponds to a declaration process 

ide{idci: sorti idcn-sortn) = proc binds the terms tmi, ■ • tmn to the 

variables idci, . . ., idcn, then runs proc. 

— A process begin ide{tmi tmn)', proc logs a begin-event labelled with ide 

and the tuple {tmi, ■ • tmn), then runs proc. 

— A process end ide{tmi tmn)', P^oc logs an end-event labelled with ide 

and the tuple {tmi, ■ • tmn), then runs proc. 

~ Finally, the process done logs a done-event. (We typically mark the successful 
completion of the whole protocol with done. Ghecking for the reachability 
of the done-event is then a basic check of the functionality of the protocol, 
that it may run to completion.) 

The main goal of the TulaFale tool is to prove or refute robust safety for all the 
correspondences declared in a script. Robust safety may be proved by a range of 
techniques; the first paper on TulaFale [BFG04a] uses manually developed proofs 
of behavioural equivalence. Instead, our TulaFale tool translates scripts into the 
applied pi calculus, and then runs Blanchet’s resolution-based protocol verifier; 
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the translation is essentially the same as originally described [BFG04a] . ProVerif 
(hence TulaFale) can also check secrecy assertions, but we omit the details here. 
In addition, TulaFale includes a sort-checker and a simulator, both of which help 
catch basic errors during the development of scripts. For example, partly relying 
on the translation, TulaFale can show the reachability of done processes, which 
is useful for verifying that protocols may actually run to completion. 



6 Modelling and Verifying Onr Protocol 

Relying on the predicates given in Section 4, we now define the processes mod- 
elling our sample system. 

6.1 Modelling the System with TulaFale Processes 

In our example, a public channel publish gives the attacker access to the certifi- 
cates and public keys of the CA and two servers, named "BobsPetShop" and 
"ChasMarket". Another channel soap is for exchanging all SOAP messages; it is 
public to allow the attacker to read and write any SOAP message. 

channel publish(item). 
channel soap(item). 

The following is the top-level process, representing the behaviour of all com- 
pliant principals. 

new sr;bytes; let kr = pk(sr); 

new sxl:bytes; let certl = x509(sr, "BobsPetShop", "rsashal",pk(sxl)); 
new sx2:bytes; let cert2 = x509(sr, "ChasMarket ","rsashal",pk(sx2)); 
out publish(base64(kr)); 
out publish(base64(certl)); 
out publish(base64(cert2)); 

( !MkUser(kr) | !MkService(sxl, certl) | !MkService(sx2,cert2) | 

(!in anyUser(U); Client(kr,U)) | 

(!in anyService(sx,cert,S); Server(sx,cert,S)) ) 

The process begins by generating the private and public keys, sr and kr, of 
the CA. It generates the private keys, sxl and sx2, of the two servers, plus their 
certificates, certl and cert2. Then it outputs the public data kr, certl, cert2 to the 
attacker. After this initialization, the system behaves as the following parallel 
composition of five processes. 

!MkUser(kr) | !MkService(sxl, certl) | !MkService(sx2,cert2) | 

(!in anyUser(U); Client(kr,U)) | 

(!in anyService(sx,cert,S); Server(sx,cert,S) 

As explained earlier, the ! symbol represents unbounded replication; each of 
these processes may execute arbitrarily many times. The first process allows the 
opponent to generate fresh username/password combinations that are shared 
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between all clients and servers. The second and third allow the opponent to 
generate fresh services with subject names "BobsPetShop" and "ChasMarket", 
respectively. The fourth acts as an arbitrary client U, and the fifth acts as an 
arbitrary service S. 

The process MkUser inputs the name of a user from the environment on 
channel gen User, then creates a new password and records the username/pass- 
word combination U as a message on private channel anyUser, representing the 
database of authorized users. 

channel genUser(string). 
private channel anyUser(item). 
process MkUser(kr:bytes) = 
in genUser(u); 
new pwd:string; 

let U = <User><Usernajne>u</><Password>pwd</></>; 
lout anyUser (U). 

The process MkService allows the attacker to create services with the subject 
name of the certificate cert. 

predicate isServiceData(S:item,sx:bytes,cert:bytes) : — 
isService(S,uri,ac,x509user(cert)), 
pk(sx) = x509key(cert). 

channel genService(item). 
private channel anyService(bytes, bytes, item), 
process MkService(sx:bytes, cert: bytes) = 
in genService(S); 
filter isServiceData(S,sx,cert) 
lout anyService(sx,cert,S). 

Finally, we present the processes representing clients and servers. Our desired 
authentication and correlation properties are correspondence assertions embed- 
ded within these processes. We declare the sorts of data to be agreed by the 
clients and servers as follows. 

correspondence Cl(item, item, string.string, item), 
correspondence C2(item, item, string, string, item, string, string, item). 

The process Client(kr:bytes,U;item) acts as a client for the user U, assuming 
that kr is the CA’s public key. 

channel init(item, bytes, bytes, string, item), 
process Client(kr:bytes,U:item) = 
in init (S,certA,n,tl,bl); 
new idlistring; 
begin Cl (U,S,idl,tl,bl); 

filter mkMsgl(msgl,U,S,kr,certA,n,idl,tl,bl) ^msgl; 
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out soap(msgl); 
in soap(msg2); 

filter isMsg2(msg2,S,kr,idl,id2,t2,b2) — >id2,t2,b2; 
end C2 (U,S,idl,tl,bl,id2,t2,b2); 

done. 

The process generates a globally fresh, unpredictable identifier idl for Mes- 
sage 1, to allow correlation of Message 2 as discussed above. It then allows the 
attacker to control the rest of the data to be sent by receiving it off the public 
init channel. Next, the TulaFale filter operator evaluates the predicate mkMsgl 
to bind variable msgl to Message 1. At this point, the client marks its intention 
to communicate data to the server by logging an end-event, labelled Cl, and 
then outputs the message msgl. The process then awaits a reply, msg2, checks 
the reply with the predicate isMsg2, and if this check succeeds, ends the C2 cor- 
respondence. Finally, to mark the end of a run of the protocol, it becomes the 
done process — an inactive process, that does nothing, but whose reachability 
can be checked, as a basic test of the protocol description. 

The process Server(sx:bytes,cert:bytes,S:item) represents a service S, with 
private key sx, and certificate cert. 

channel accept(string, string, item), 
process Server(sx:bytes,cert;bytes,S:item) = 
in soap(msgl); 
in anyUser(U); 

filter isMsgl(msgl,U,sx, cert, S, idl, tl,bl) — >idl,tl,bl; 
end Cl (U,S,idl,tl,bl); 

in accept (id2,t2,b2); 

filter mkMsg2(msg2,sx, cert, S, idl, id2,t2,b2) ^ msg2; 
begin C2 (U,S,idl,tl,bl,id2,t2,b2); 
out soap(msg2). 

The process begins by selecting a SOAP message msgl and a user U off the 
public soap and the private anyUser channels, respectively. It filters this data 
with the isMsgl predicate, which checks that msgl is from U, and binds the 
variables S, idl, tl, and bl. At this point, it asserts an end-event, labelled Cl, to 
signify apparent agreement on this data with a client. Next, the process inputs 
data from the opponent on channel accept, to determine the response message. 
The server process completes by using the predicate mkMsg2 to construct the 
response msg2, asserting a begin-event for the C2 correspondence, and finally 
sending the message. 

6.2 Analysis 

The TulaFale script for this example protocol consists of 200 lines specific to 
the protocol, and 200 lines of library predicates. (We have embedded essentially 
the whole script in this paper.) Given the applied pi calculus translation of this 
script, ProVerif shows that our two correspondences Cl and C2 are robustly 
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safe. Failure of robust safety for Cl or C2 would reveal that the server or the 
client has failed to authenticate Message 1, or to authenticate Message 2 and 
correlate it with Message 1, respectively. Processing is swift enough — around 25s 
on a 2.4GHz 1GB P4 — to support easy experimentation with variations in the 
protocol, specification, and threat model. 



7 Conclusions 

TulaFale is a high-level language based on XML with symbolic cryptography, 
clausally-defined predicates, pi calculus processes, and correspondence asser- 
tions. Previous work [BFG04a] introduces a preliminary version of TulaFale, 
defines its semantics via translation into the applied pi calculus [AFOl], illus- 
trates TulaFale via several single-message protocols, and describes hand-crafted 
correctness proofs. 

The original reasons for choosing to model WS-Security protocols using the 
the pi calculus, rather than some other formal method, include the generality 
of the threat model (the attacker is an unbounded, arbitrary process), the ease 
of simulating executable specifications written in the pi calculus, and the exis- 
tence of a sophisticated range of techniques for reasoning about cryptographic 
protocols. 

Blanchet’s ProVerif [BlaOl, Bla02] turns out to be a further reason for using 
the pi calculus to study SOAP security. Our TulaFale tool directly implements 
the translation into the applied pi calculus and then invokes Blanchet’s verifier, 
to obtain fully automatic checking of SOAP security protocols. This checking 
shows no attacker expressible as a formal process can violate particular SOAP- 
level authentication or secrecy properties. Hence, we expect TulaFale will be 
useful for describing and checking security aspects of web services specifica- 
tions. We have several times been surprised by vulnerabilities discovered by the 
TulaFale tool and the underlying verifier. Of course, every validation method, 
formal or informal, abstracts some details of the underlying implementation, so 
checking with TulaFale only partially rules out attacks on actual implementa- 
tions. Still, ongoing work is exploring how to detect vulnerabilities in web ser- 
vices deployments, by extracting TulaFale scripts from XML-based configuration 
data [BFG04b]. 

The request/response protocol presented here is comparable to the abstract 
RPG protocols proposed in earlier work on securing web services [GP03], but 
here we accurately model the SOAP and WS-Security syntax used on the wire. 
Gompared with the SOAP-based protocols in the article introducing the TulaFale 
semantics [BFG04a], the novelties are the need for the client to correlate the 
request with the reply, and the use of encryption to protect weak user passwords 
from dictionary attacks. In future work, we intend to analyse more complex 
SOAP protocols, such as WS-SecureGonversation [KN+04], for securing client- 
server sessions. 

Although some other process calculi manipulate XML [BS03, GM03], they are 
not intended for security applications. We are beginning to see formal methods 
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applied to web services specifications, such as the TLA+ specification [JLLV04] 
of the Web Services Atomic Transaction protocol, checked with the TLC model 
checker. Still, we are aware of no other security tool for web services able to 
analyze protocol descriptions for vulnerabilities to XML rewriting attacks. 

Acknowledgement. We thank Bruno Blanchet for making ProVerif available, 
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Bertocci, Ricardo Corin, Amit Midha, and the anonymous reviewers made useful 
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Abstract. We present a new technique for the automatic verification of 
first order modal /i-calculus formulae on infinite state, data-dependent 
processes. The use of boolean equation systems for solving the model- 
checking problem in the finite case is well-studied. We extend this 
technique to infinite state and data-dependent processes. We describe a 
transformation of the model checking problem to the problem of solving 
equation systems, and present a semi-decision procedure to solve these 
equation systems and discuss the capabilities of a prototype implement- 
ing our procedure. This prototype has been successfully applied to many 
systems. We report on its functioning for the Bakery Protocol. 

Keywords: Model Checking, /rCRL, First Order Modal /i-Calculus, 
First Order Boolean Equation Systems, Data-Dependent Systems, In- 
finite State Systems 



1 Introduction 

Model checking has come about as one of the major advances in automated ver- 
ification of systems in the last decade. It has earned its medals in many applica- 
tion areas (e.g. communications protocols, timed systems and hybrid systems), 
originating from both academic and industrial environments. 

However, the class of systems to which model checking techniques are ap- 
plicable, is restricted to systems in which dependencies on infinite datatypes 
are absent, or can be abstracted from. The models for such systems therefore 
do not always represent these systems best. In particular, for some systems the 
most vital properties are sensitive to data. There, the model checking technique 
breaks down. This clearly calls for an extension of model checking techniques for 
systems that are data-dependent. 

In this paper, we explore a possibility for extending model checking techniques 
to deal with processes which can depend on data. We describe a procedure, for 
which we have also implemented a prototype, that verifies a given property 
on a given data-dependent process. The problem in general is easily shown to 
be undecidable, so, while we can guarantee soundness of our procedure, we 
cannot guarantee its termination. However, as several examples suggest, many 
interesting systems with infinite state spaces can be verified using our procedure. 
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Naturally, our technique also applies to systems with finite (but extremely large) 
state-spaces. 

The framework we use for describing the behaviour of a system is process 
algebraic. We use the process algebraic language ^CRL [10, 11], which is an ex- 
tension of AGP [2] ; this language includes a formal treatment of data, as well as 
an operational and axiomatic semantics of process terms. Compared to CCS or 
AGP, the language /iCRL is more expressive [17]. For our model checking pro- 
cedure, we assume that the processes are written in a special format, the Linear 
Process Equation (LPE) format, which is discussed in e.g. [23]. Note that this 
does not pose a restriction on the set of processes that can be modelled using 
^CRL, as all sensible process descriptions can be transformed to this format [23]. 
When dealing with datatypes, an explicit representation of the entire state space 
is often not possible, since it can very well be infinite. Using the LPE format has 
the advantage of working with a finite representation of the (possibly infinite) 
state space. 

The language we use to denote our properties in is an extension of the modal 
/i-calculus [16]. In particular, we allow first order logic predicates and param- 
eterised fixpoint variables in our properties. These extensions, which are also 
described in e.g. [9], are needed to express properties about data. 

The approach we follow is very much inspired by the work of e.g. Mader [18], 
and uses (in our case, first order) boolean equation systems as an intermediate 
formalism. We present a translation of first order modal /r-calculus expressions 
to first order boolean equation systems in the presence of a fixed Linear Process 
Equation. The procedure for solving the first order boolean equation systems is 
based on the GauB elimination algorithm described in, e.g. [18]. 

This paper is structured as follows: Section 2 briefly introduces the language 
/iCRL and the Linear Process Equations format that is used in all subsequent 
sections. In Section 3, we describe the first order modal /li-calculus. Section 4 
discusses first order boolean equation systems and describes the translation of 
first order modal /i-calculus formulae, given a Linear Process Equation, to a 
sequence of first order boolean equations. A procedure for solving the first order 
boolean equations is then described in Section 5; its implementation is discussed 
in Section 6, and a sample verification is described in Section 7. Section 8 is 
reserved for concluding remarks. 

2 Preliminaries 

Our main focus in this paper is on processes with data. As a framework, we use 
the process algebra /iCRL [10]. Its basic constructs are along the lines of AGP [2] 
and CCS [20], though its syntax is influenced mainly by AGP. In the process 
algebra /iCRL, data is an integral part of the language. For the exhibition of 
the remainder of the theory, we assume we work in the context of a data alge- 
bra without explicitly mentioning its constituent components. As a convention, 
we assume the data algebra contains all the required data types; in particular. 
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we always have the domain B of booleans with functions T :^B and _L:^B, 
representing true and false at our disposal. 

The language /iCRL has only a small number of carefully chosen operators 
and primitives. Processes are the main objects in the language. A set of param- 
eterised actions Act is assumed. Actions represent atomic events; for an action 
a&Act, taking a number of data arguments d, a{d) is a process. The process 
representing no behaviour, i.e. the process that cannot perform any actions is 
denoted 6. This constant is often referred to as deadlock or inaction. All actions 
a terminate successfully immediately after execution; 6 cannot be executed. 

Processes are constructed using several operators. The main operators are 
alternative composition {p + q for some processes p and q) and sequential com- 
position {p ■ q for some processes p and q) . Conditional behaviour is denoted 
using a ternary operator (we write p <\b> q when we mean process p if b holds 
and else process q). The process [b]:^p serves as a shorthand for the process 
p<b>6, which represents the process p under the premise that b holds. Recursive 
behaviour is specified using equations. Process variables are typed; they should 
be considered as functions from a data domain to processes. 

Example 1. The behaviour, denoted by process X{n) is the increasing and de- 
creasing of an internal counter n or showing its current value. 

A(n:N) = up • X{n+1) + show{n) • X{n) -I- [n > 0]:^down • X{n—1) 

For the formal exposition, it can be more convenient to assume that actions 
and processes have a single parameter. This assumption is easily justified, as we 
can assume the existence of an appropriate data domain, together with adequate 
pairing and projection functions. 

A more complex notion of process composition consists of the parallel com- 
position of processes (we write p\\q to denote the process p parallel to the process 
q) . Synchronisation is achieved using a separate partial communication function 
7 , prescribing the result of a communication of two actions (e.g. 7 ( 0 , b) = c de- 
notes the communication between actions a and b, resulting in action c). Two 
parameterised actions a{n) and b{n') can communicate to action c{n") only if 
the communication between actions a and b results in action c (i.e. ^{a,b) = c) 
and n" = n' = n. 

The communication function is used to specify when communication is pos- 
sible; this, however, does not mean communication is enforced. To this end, we 
must encapsulate the individual occurrences of the actions that participate in 
the communication. This is achieved using the encapsulation operator (we write 
dnip) to specify that all actions in the set of actions H are to be encapsulated 
in process p) . 

The last operator considered here is data-dependent alternative quantification 
(we write to denote the alternatives of process p, dependent on some 

arbitrary datum d selected from the (possibly infinite) data domain D). The 
^-operator is best compared to e.g. input prefixing, but is more expressive (see 
e.g. [17]). 
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Example 2. The behaviour, denoted by process V (n) is the setting of an internal 
variable to an arbitrary value, which can be read at will. 

y(n:N) = read{n) ■V{n) + ^ set{n') ■ V{n') 

n'-M 

For the purpose of verification or analysis, it is often most convenient to elim- 
inate parallelism in favour of sequential composition and (quantified) alternative 
composition. A behaviour of a process can then be denoted as a state-vector of 
typed variables, accompanied by a set of condition-action-effect rules. Processes 
denoted in this fashion are called Linear Process Equations. 

Definition 1. A Linear Process Equation (LPE) is a parameterised equation 
taking the form 

X{d:D) = ^ ^ [a{d,ei)] ai{fi{d,ei)) ■ X{gi{d,ei)) 

iGl ei'.Di 

where L is a finite index set; D and Di are data domains; d and are data 
variables; ai&Act are actions with parameters of sort DaX, fp-D x Di ^ Da^, 
gp.D X Di D and cp.D x Di —> M are functions. The function fi yields, on the 
basis of the current state d and the bound variable Ci, the parameter for action 
ai; the “next-state” is encoded in the function gi. The function Ci describes when 
action Oj can be executed. 



In this paper, we restrict ourselves to the use of non-terminating processes, 
i.e. we do not consider processes that, apart from executing an infinite number 
of actions, also have the possibility to perform a finite number of actions and 
then terminate successfully. Including termination into our theory does not pose 
any theoretical challenges, but is omitted in our exposition for brevity. 

Several techniques and tools exist to translate a guarded y^CRL process to 
linear form (see e.g. [3, 23]) and to further analyse these processes using symbolic 
manipulation. In the remainder of this paper, we use the LPE-notation as a 
vehicle for our exposition of the theory and practice. 

The operational semantics for /xCRL can be found in e.g. [10, 11]. Since we 
restrict our discussions to process expressions in LPE-form, we here only provide 
a definition of the labelled transition system that is induced by a process in LPE- 
form. 



Definition 2. The labelled transition system of a Linear Process Equation X 
as defined in Def. 1 is a quadruple M = {S, sq) , where 



— S = {X{d) \ dGD} is the (possibly infinite) set of states ; 

— E = {afidafi 1 i€l AaiGActAdaiGDai} is the (possibly infinite) set of labels; 
>= {{X{d),ai{d'^),X{d')) \ iGL A OiGAct A 3e,gD,Ci(d, e*) Ad'^ = fi{d,ei) A 



d' = gfidjCi)} is the transition relation. We write X(d) 
than {X{d),a{e), X{d'))G 

— Sq = X{do)GS, for a given dgGD, is the initial state. 



X{d') rather 
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3 First Order Modal /r-Calculus 

The logic we consider is based on the modal /t-calculus [16], extended with 
data variables, quantifiers and parameterisation (see [9]). This logic allows us to 
express data dependent properties. We refer to this logic as the first order modal 
fi-calculus. Its syntax and semantics are defined below. 

Definition 3. An action formula is defined by the following grammar 
a ::= a(e) | T | -^a\ | «i A 02 | yd:D.ai 

Here, a is a parameterised action of set Act and e of datatype D, is some data 
expression, possibly containing data variables d of a set T>. We use the standard 

d d d G^ 

abbreviations A = HT , (cti V 02 ) = A ^ 02 ) and {3d\D.ai) = {-A/d\D.^ai). 

The action formulae are interpreted over a labelled transition system M, 
which is induced by an LPE (see Def. 2). 

Remark 1. We use environments for registering the (current) values of variables 
in formulae. Hence, an environment is a (partial) mapping of a set of variables 
to elements of a given type. We use the following notational convention: for an 
arbitrary environment 9, a variable x and a value v, we write 9[v/x\ for the 
environment 9' , defined as 9'{x') = 9{x') for all variables x' different from x and 
9'(x) = V. In effect, 9[vlx] stands for the environment 9 where the variable x 
has value v. The interpretation of a variable x in an environment 9 is written as 
9{x). 

Definition 4. The interpretation of an action formula a in the context of a 
data environment e:T>^D, denoted by |a]e, is defined inductively as: 

[Tie = 2: 

[a(e)le = {a(£(e))} 

l^aje = S \ lajs 

[oi A a2js = |ai]e n |a2le 

[Vd:I?.a]£ = |a]£[f/d] 

Hence, we can use T to denote an arbitrary (parameterised) action. This is 
useful for expressing e.g. progress conditions. We subsequently define the set of 
state formulae. 

Definition 5. A State Formula is given by the following grammar. 

ip ■.-.= b\ Z{e) I ^ 7 ? I 7>i A v ?2 I VAti I yd'.D.p \ {vZ{d\D).ip){e) 

where b is an expression of the domain B, possibly containing data variables d 
of the set V, e of datatype D, is some data expression possibly containing data 
variables d of the set V, a is an action formula; Z is a propositional variable from 
a set V, and {vZ{d\D).ip){e) is subject to the restriction that any free occurrence 
of Z in (p must be within the scope of an even number of negation symbols. 
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d cf d &f 

We use the abbreviations as usual: {ipi V (p 2 ) = ~'{^‘Pi A {o:)(p = ^[a]^(p, 

(3d:D.ip) = {-di d'.D .^Lp) and {p,Z{d\D).Lp){e)'^={-^vZ{d\D).^ip[-^Z/Z]){e). We 
write a for an arbitrary fixpoint, i.e. a € {v, p,}. 

We only consider state formulae in which all variables are bound exactly 
once by a fixpoint operator or quantifier. State formulae are interpreted over a 
labelled transition system M, induced by an LPE, according to Def. 2. 

Definition 6. The interpretation of a state formula (p in the eontext of data 
environment e:T>^D and propositional environment p:V^{D^2^) , denoted by 
is defined inductively as: 



Ibjpe 

lZ{e)jpe 

hvlpe 

\ipi A ip2\pe 

IVAtIrs 



fid:D.<p\pe 

l{vZ{d-.D).p){e)lpe 



(S if Ibje 
\ 0 otherwise 
p(Z)(e(e)) 

S \ {ip\pe 
{ipilpe n \ip 2 lpe 

{Ar(u)eS' I Vu'gD 'ia&Act Vva&Da 
(^X{v) X{v') A a(z;a)G[al£) ^ XivA^Mpe} 

n«'er> Mp(4v'/d]) 

(j/^pe)(e(e)) 



where we have <Ppg=^XF:D 2^ ,\v:D .l(p]{p[F / Z]){e[v / d\) . For states X{d) G S 

of the transition system induced by an LPE X, and a formula (p, we write d \=x T 
for X{d) G Mpe. 



Remark 2. In the remainder of this paper, we restrict ourselves to state formulae 
given in Positive Normal Form (PNF). This means that negation only occurs on 
the level of atomic propositions and, in addition, all bound variables are distinct. 

We denote the set of functions D— >2‘® by [D^2^\. Define the ordering C on 
the set [D— >2'^] as XCY iff for all d:D we have X{d) CP (d). Then, the fixpoint 
operators are monotonic over the complete lattice ([D— >2'®], C) (see [14,24]). 
From this, the existence and uniqueness of fixpoints in state formulae immedi- 
ately follows. 

Example 3. Standard (first order) modal /r-calculus formulae often consist of the 
constructs vZ.{\J]Z Xp) and pZ.{p\J ([T]Z A (T)T)). These formulae represent 
“always and “eventually (/?” resp. The greatest fixpoint can be interpreted as 
“infinitely often” , whereas the least fixpoint can be interpreted as “finitely many 
times” . 



Example 4- Consider a process with at least the states sq,si and S 2 , the labels 
a(T) and a(T) and the state formula p. We write s |= (p to denote that p is 
satisfied in state s, and, likewise, we write s p to denote that p is not satisfied 
in state s. 
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1. The state formula 36:B. [a{b)]ip holds in state sq; 
since there is a 6 (viz. & = T), such that whenever 
we execute a{b), we end up in a state satisfying 

f- 

2. The state formula does not hold in 

state So, since by executing a(T) we end up in 
a state not satisfying ip. An alternative phrasing 
of the same property is yb:M.[a{b)]ip. 




Note that data-quantification in action formulae can be used for abstracting 
from the actual values for parameterised actions. One may be led to believe that 
the quantifiers inside modalities can all be replaced by quantifiers in state for- 
mulae. This, however, is not true, as we can only derive the following properties. 



Property 1. Let ip he a, state formula, such that d does not occur in ip, and let 
a be an action formula. Then, we have the following identities: 

1. {3d:D.a)p 3d:D.{a)p, and [3d:D.a]p Vd:I?.[a]v3, 

2. 3d:D.[a]p ^ ['id:D.a]p, and {yd:D.a)p yd:D.{a)p 

Note: here we use implication as an abbreviation for C and bi-implication as an 
abbreviation for = on the interpretations of the state formulae. 

These properties state a weak relation between quantifiers in state formulae 
and quantifiers in action formulae. Note that the converse of the second item 
does not hold, see e.g. [14, 24] for a counterexample. Thus, compared to the frag- 
ment of the first order modal /i-calculus that disallows quantifiers inside action 
formulae, the quantifiers inside action formulae indeed increase the expressive 
power of the whole first order modal /r-calculus. 

Remark 3. Note that negation in combination with universal quantifiers in ac- 
tion formulae can yield more exciting sets than the empty set. 



4 Equation Systems 

Following [9], we use an extension of the formalism of boolean equation systems 
(see e.g. [18]) as an intermediate formalism that allows us to combine an LPE 
with a first order modal y:i-calculus expression. 

Definition 7. A first order boolean expression is a formula p in positive form, 
defined by the following grammar: 

p ::= b \ Pi f\ p 2 \ pi\/ P 2 \ Z{e) \ Vd:D.p \ 3d:D.p 

where b is an expression of datatype B, possibly containing data variables d of 
a set V, Z is a variable of a set V of propositional variables and e is a term of 
datatype D, possibly containing data variables d of a set T>. 
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We denote the set of functions of type D^M by . The set of first order 

boolean expressions ([I?— >B], ^), where iff for all d:D ip{d)^tp{d), forms a 

complete lattice and is isomorphic to (2^ , C). The propositional variables ZgV, 
occurring as free variables in first order boolean expressions are bound in first 
order boolean equation systems (also known as parameterised boolean equation 
systems [15] or equation systems for short), used in the sequel. 

Definition 8. The interpretation of a first order boolean expression ip in the 
context of propositional environment 9\V^{D^W) and data environment 
rj-.V^D, written as |</3]077 is either true or false, determined by the following 
induction: 

= Ibjrj 

{ifi A (^2]0?7 = ItiWti a Ip2l0ri 
{ifi V ^21071 = IpilOrj V Iip2l0ri 
lZ{e)\6p = 6{Z){{elr,) 

d\D .ip\9rj = true, if for all v:D it holds that |(/?]0(r7[w/(i]) else false 
l3d:D.ifil9ri = true, if there exists a v:D such that |v3]6*(?7[-u/cf|) else false 

Lemma 1 . First order boolean expressions are monotone over ([D^B],^), 
see [If, 2f[. 

Definition 9. An equation system E is a finite sequence of equations of the 
form aZ{d:D) = p, where a is u or p and is a first order boolean 

expression. We require that all data variables are bound exactly once and all 
bound propositional variables are unique; e represents the empty equation system. 

The equation system £' that is obtained by applying an environment 9 to an 
equation system £ is the equation system in which every propositional variable 
Z is assigned the value 9{Z). 

Definition 10 . The solution [£]9 to the equation system £ (containing only 
bound data variables), in the context of propositional environment 9 , 
is an environment that is defined as follows (see also e.g. [18], Definition 3.3). 

1) [e]9 = 9, and 2) [{aZ{d:D) = p)£]9 = [£]{9[aZ.p{[£]9) /Z]), where 

pZ.p{[£\9) = ^ B I \d-.D.lp\{[£]9[flZ])^i,} 

vZ.p{\£]9) = \/{f)-.D^M I f)^Xd-.D.\p\{\£]9[f/Z])} 

where f\ and \J denote the infimum and the supremum from ([D— >B], ^). 

We denote the set of all environments by [7^— >(D^B)j. The set <) 

is a complete lattice, where the ordering < is defined as 6*i < 02 iff for all Z G V, 
we have 9i{Z)Gp92{Z). 

Lemma 2. Equation systems are monotone over ([7^— >(Z1^B)], <), see [If, 2f[. 

We subsequently transform the model-checking problem for processes with 
data to the problem of finding the solution to an equation system. We define a 
translation, transforming an LPE and a first order modal /i-calculus formula to 
an equation system. 
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Definition 11. Let ip = {aZ{df:D).<P)(e) be a first order modal p-calculus for- 
mula ip. Let X{dp\D) he an LPE (see Def. 1 ). The equation system £ that corre- 
sponds to the expression p for LPE X is given by E(<p) . The translation function 
E is defined by structural induction in Table 1. 

Theorem 1. Let X he an LPE with initial state X{dfi) and parameter space 
D. For each environment p:V^{D'^2^) the environment 9p:V^{DxD'^M) 

is defined as 9p{Z)'^=\{d^d')\DxD' .{X{d)&p{Z){d')). Let p= {aZ{d\D').T>){e). 
Then, we have 

do P tffmT)]&p)(Z(.e,do)) 

Proof. See [9]. 

The translation function E splits nested fixpoint expressions into equations 
for which the right-hand side is determined by the function RHS. This latter 
function takes care of the logical connectives, such as A and V, and the modalities 
[a]p and {a)p. 

Example 5. Consider a coffee-vending machine that produces either cappuccino 
or espresso on the insertion of a special coin. It accepts coins as long as there 
is at least one type of coffee that can still be dispensed. If the machine has run 
out of a type of coffee, it can be filled again with C fillings of cappuccino or E 
fillings of espresso. 

proc X{b:M, c, e:N) = [6 A c > 0]:^ cappuccino ■ X{^b, c — 1, e) 

-|-[6 A e > 0]:^ espresso • X{^b, c, e — 1) 

-|-[^6 A c -I- e > 0]:^ coin ■ X{^b, c, e) 

-t-[ L Ac 0] . > ^^fi^fiappuccino ' ^(^7 
-\-[^b A e = 0]:^ refilfi.p^^,.,.^ ■ X{b, c, E) 

Boolean b indicates whether a coin has been inserted or not and parameters 
c and e register the number of servings of cappuccino, resp. espresso that are 
left in the coffee-vending machine. Consider the (first order) modal /i-calculus 
expression pZ.{{coin\J cappuccino) Z V expressing that there 

exists a path where cappuccino can be refilled when it is the only thing that has 
been ordered. We briefly illustrate how we can obtain an equation system by 
combining process X and the above modal formula using Def. 11: 

E(^Z.((comV cappuccino)ZV 
= c, e:N) = RHS(((comV cappuccino) Z y 

= c, e:N) = RHS((comV cappuccino) Z) V RHS((re/iZZg„pp„ggj„o)T)) 

= {pZ{b:M,c,e:N) = (-5 A c -k e > 0 A RHS(Z)[(^5, c, e)/(5, c, e)]) 

V(&Ac> 0ARHS(Z)[(^5,c- l,e)/(6, c, e)]) 

V(^6 A c = 0 A RHS(T) [(6, C, e) /(&, c, e)])) 

= {pZ{b:M, c, e:N) = {^b A(c=0V(c-|-e>0A Zfi^b, c, e)))) 

V(5 A c > 0 A Zip^b, c — 1, e)) 

Notice that this equation carries the parameters of the LPE, even though the 
first order modal /i-calculus expression was not parameterised. 
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Table 1. Translation of first order ^-calculus formula ip and LPE X{dp\D) to an 
equation system E((p). Note that Z is a fresh propositional variable, associated to the 
propositional variable Z. Function E determines the number and order of equations for 
E((p), whereas function RHS breaks down p to obtain first order boolean expressions 
that form the right-hand side of each eqnation in E(^). The satisfaction relation |= and 
the function Par are listed in Table 2. The fnnction Parx ipp) yields a list of parameters 
with types that must be bound by the parameterised propositional variable X. Here, 
we have abused the notation Parx(v3) to also denote the list of parameters without 
typing information. Note that Parx(v5) is always calculated for the entire formula p, 
and not for subformulae 



E(6) 


def 


e 


nz{df)) 


def 


e 


E(^i A <?2) 


def 


E(<?i)E(<?2) 


E(^i V ^ 2 ) 


def 


E(<?i)E(<?2) 


E([a]^>) 


def 


E(^>) 


E((a)<^>) 


def 


E(^>) 


E(Vd:D.<?) 


def 


E(^>) 


E(3d:D.<?>) 


def 


E(^>) 




def 


{aZ{df.Df,dp-.Dp,VsiVz{p)) = RHS(^) ) E(<?) 


RHS(5) 




def 7 

= 0 


RHS(Z(e)) 




Z{e,dp,Parz{(p)) 


RHS(<?i A ^> 2 ) 




RHS(^>i) A RHS(^>2) 


RHS(<l>i V ^> 2 ) 




= RHS(^>i) VRHS(<?2) 


RHS(H^) 




— f\i'l 'dei’.Di (c^i (fz (dp, Cz)) ^ Ct A Cii^dp^ t^z)) 

R.US{d>)[g,{dp,e,)/dp] 


RHS((a)<?) 




— Vz*/ (ft (dp, 6z)) ^ A Cz(dp, e^A 
RHS(^)[5z(dp,ez)/dp]) 


RHS(Vd:D.^<) 




Vd:£i.RHS(^>) 


RHS(3d:D.^>) 




3d:Zl.RHS(^>) 


RHS((CTZ(dy:£>/).<?>)(e)) 


Z{e, dp, Par z{(p)) 



5 Model-Checking 

Mader [18] describes an algorithm for solving boolean equation systems. The 
method she uses resembles the well-known Gaufi elimination algorithm for solv- 
ing linear equation systems, and is therefore also referred to as GauB elimination. 
The semi-decision procedure we use (see Fig. 1) is an extension of the GauB elim- 
ination algorithm of [18]. Basically, all lines (except for line 3) are part of the 
algorithm of [18]. The essential difference is in the addition of line 3, where an 
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Table 2. Auxiliary functions used in the translation of Table 1. Here, + denotes list 
concatenation. The satisfaction relation \= checks whether a symbolic action a{d) is 
part of an action formula a. The function Parx (v?) yields a list of parameters together 
with their types that have to be bound by the equation for X 



a{d) h a'(d') 


def 


II 

< 

II 


a{d) h T 


def 


true 


a{d) 1 = 


def 


~^{a{d) h a) 


a{d) 1 = a 1 A 02 


def 


{a{d) 1 = oi) A (a(d) ^ 02) 


a{d) 1 = ai V 02 


def 


(a{d) 1 = oi) V (a{d) \= 02) 


a{d) ^ 3d':D.a 


def 


3d':D.{a{d) h a) 


a{d) h yd':D.a 


def 


yd':D.{a{d) h a) 


Parx{b) 




= [] 


Par x{Z{df)) 




[] for all Z eV 


Parx(^i A <^2) 




= Parx(^i) -ffParx(^2) 


Parx(^i V <p2) 




=^Parx(^i) -ffParx(^ 2 ) 


Parx{[a]^) 




=^Parx(<^) 


Parx{{a)F) 




=^Parx(^) 


Paxx{yd:D.(p) 




= [d-.D] ^Parx(<?) 


Paxx{3d:D.(p) 




[d:D] ^Parxi^) 


Parx{{aZ{df.Df).F){e)) = Parx{^) for all Z G 


Parx{{aX{df.Dj).<P){e))‘^^^[] 



extra loop for calculating a stable point in the (transfinite) approximation for 
each equation is given. 

The reduction of an equation system proceeds in two separate steps. First, 
a stabilisation step is issued, in which an equation <TiXi{d\D) = ipi is reduced 
to a stable equation aiXi{d:D) = where is an expression containing no 
occurrences of Xi. Second, we substitute each occurrence of Xi by in the 
rest of the equations of the first order boolean equation system. This does not 
change the solution of the equation system (see [14,24, 15]). Since there are no 
more occurrences of Xi in the right-hand side of the equations, it suffices to 
reduce a smaller equation system. The semi-decision procedure terminates iff 
the stabilisation step terminates for each equation. 

Theorem 2 . On termination of the semi-decision procedure in Fig. 1, the so- 
lution of the given equation system has been computed [ 14 , 24 ]- 

Remark 4- Given the undecidability of the model-checking problem in the set- 
ting of (arbitrary) infinite state systems, the stabilisation step in our procedure 
(which is based on transfinite approximations of fixpoints) cannot be made to 
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Input: {aiXi{di:Di) = (pi) . . . = ip„)- 

1 . for i = n downto 1 do 

2. j := 0; ipo := ( if (Jbj = then T else _L); 

3. repeat ipj+i := p,[Xi := j := j + 1 until {tpj = 

4. for fc = 1 to i do := Pk[^i '■= '>Pj] ; 

5. od 



Fig. 1. Semi-decision procedure for computing the solution of an equation system 



terminate. However, there are a number of cases for which termination is guar- 
anteed, e.g. if all considered datatypes are finite. 

Example 6. Consider the infinite-state system C(0) that counts from zero to 
infinity, and reports its current state via an action current. Even though 
this process is not very complex, it cannot be represented by a finite labelled 
transition system, which is why most current tools cannot handle such 
processes. 

proc C(n:N) = current{n) ■ C{n+1) 

Verifying absence of deadlock, i.e. :^Z.((T)T A [T]Z) on process C requires 
solving the associated equation system i^Z(n:N) = {Z{n+1) A T). Substituting 
T for Z{n+1) immediately leads to the stable solution T. 

Example 7. Consider a process C representing a counter that counts down from 
a randomly chosen natural number to zero and then randomly selects a new 
natural number. 

proc C(n:N) = ^ [n = 0]:^ reset - C{m) -I- [n > 0]:— > dec - C(n— 1) 
m:N 

Verifying whether it is possible to eventually execute a reset action, expressed 
by the formula pLZ.{\J]Z f\(T)T) V (reset)T, requires solving the equation system 
p,Z{n:N) = (n = 0 V (Z(n—1) A (n = 0 V n > 0))). Here, the approximation of Z 
does not stabilise in a finite time, as we end up with approximations ^|Jk, where 

= n < k. Thus, we cannot find a such that il)j = ipj+i- However, it 
is straightforward to see that the minimal solution for this equation should be 
fiZ{n:N) = T. In [15], we set out to investigate techniques and theorems that 
allow one to solve (by hand) a substantially larger class of equation systems than 
the class that can be solved using our semi-decision procedure of Figure 1. This 
class includes equation system of the type of this example. 




A Checker for Modal Formulae for Processes with Data 



235 



6 Implementation 

Based on our semi-decision procedure, described in the previous section, we 
have implemented a prototype of a toob . The prototype implementation of our 
algorithm employs Equational Binary Decision Diagrams (EQ-BDDs) [13] for 
representing first order boolean expressions. These EQ-BDDs extend on standard 
BDDs [6] by explicitly allowing equality on nodes. We first define the grammar 
for EQ-BDDs. 

Definition 12. Assume a set P of propositions and a set V of variables, then 
EQ-BDDs are formulae, determined by the following grammar. 

<l> ::= 0 I 1 I ITE{V = \ ITE{P,^,^) 

The constants 0 and 1 represent false and true. An expression of the form 
ITE((/?,'0,^) must be read as an if-then-else construct, i.e. {ipAif)V {-^(pAf), or, 
alternatively, (tp ^ if) A ^)- For data variables d and e, and (p of the form 

d= e, the extension to EQ-BDDs is used, i.e. we explicitly use ITE(d = 
in such cases. Using the standard BDD and EQ-BDD encodings [6, 13], we can 
then represent all quantifier-free first order boolean expressions. 

Representing expressions that contain quantifiers over finite domains is done 
in a straightforward manner, i.e. we construct explicit encodings for each distinct 
element in the domain. Expressions containing quantifiers over infinite domains 
are in general problematic, when it comes to representation and calculation. The 
following theorem, however, identifies a number of cases in which we can deal 
with these. 

Theorem 3. Quantification over datatypes can be eliminated in the following 
cases: 

3d:D.ITE{d = ei,(pi,ITE{d = 62, <P 2 , ■ ■ ■ , ITE{d = e„, fj) . . .)) 

~ V l<i<n((Al<j<i A Ci) ^ Vi[^i/d]) V 

yd-.D.ITE{d = ei,(fii,ITE{d = 62, ITE{d = e„, tp ) . . .)) 

= Ai<*<„((Vi<j-<i e^- = e*) V Pi[e,/d\) A ip 

provided D contains at least one element not in {ei\\ < i < n\. By abuse 
of notation we write Ci instead of its value. 

Proof. See [24]. 

Even though Theorem 3 applies to a restricted class of first order boolean 
expressions, we find that in practice, it adds considerably to the verification 
power of the prototype implementation. 



The tool, called MuCheck, is distributed as part of the ^CRL tool-suite [3]. 



1 
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7 Example Verification 

We have successfully used the prototype on several applications, including many 
communications protocols, such as the IEEE-1394 firewire, sliding window proto- 
cols, the bounded retransmission protocol, etc. As an example of its capabilities, 
we here report on our findings for Lamport’s Bakery Protocol [21]. A /rCRL 
specification of the Bakery Protocol is given in Fig. 2. The bakery protocol we 



comm get^ send = c 

init d{get, send}(^‘(T)||P(-L)) 



proc P{b'M) = request{b) ■ Po{b,0) + send{b,0) ■ P{b) 

proc get{^b, m) ■ Pi{b, to -I- 1) -I- send{b, n) ■ Po{b, n) 

proc Pi( 6 :B,n:N) = 

send{b, n) • Pi{b, n) + to) • (Ci(&, n) <in < to V to = 0 > Pi(&, n)) 

proc Ci{b:M,n:N) = enter{b) ■ 62(6,71) -I- send{b,n) ■ Ci{b,n) 
proc C 2 ( 6 :B, n:N) = leave{b) ■ P{b) + send{b,n) ■ C 2 {b,n) 



Fig. 2. Lamport’s Bakery Protocol 

consider is restricted to two processes. Each process, waiting to enter its critical 
section, can choose a number, larger than any other number already chosen. 
Then, the process with the lower number is allowed to enter the critical section 
before the process with the larger number. Due to the unbounded growth of 
the numbers that can be chosen, the protocol has an infinite state-space. How- 
ever, our techniques are immediately applicable. Below, we list a number of key 
properties we verify for the bakery protocol. 

1. No deadlocks, i.e. 
nZ.{[T]ZA{T)T), 

2. Two processes can never be in the critical section at the same time, i.e. 
iyZ.{[T]Z A \/b-M.{[enter{b)]i'Z' .{[enter{^b)]F A [~^leave{b)]Z'))) , 

3. All processes requesting a number eventually enter the critical section, i.e. 
iyZ.[[T]Z Ayb:M.{[request{b)]fiZ' .{{[T]Z' A (T)T) V {enter{b))T))) 

The first two properties are satisfied. Using our prototype we were able to 
produce these results in 1 and 2 seconds^ resp. The third property was proved 
not to hold in 1 second. 

8 Closing Remarks 

Related Work. In a setting without data, the use of boolean equation systems for 
the verification of modal /x-calculus formulae on finite and infinite state systems 



^ These results were obtained using a 1.47Ghz AMD Athlon XP1700-(- machine with 
256Mb main memory, running Linux kernel 2.2. 
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was studied by Mader [18]. As observed by Mader, the use of boolean equation 
systems is closely related to the tableau methods of Bradfield and Stirling [5], 
but avoids certain redundancy of tableaux. It is therefore likely that in the case 
with data our approach performs better than tableau methods if these would be 
extended to deal with data. 

Closely related to our work is the tool Evaluator 3.0 [19], which is an on- 
the-fly model checker for the regular alternation- free /r-calculus. The machinery 
of this tool is based on boolean equation systems. Although the alternation- 
free /x-calculus allows for the specification of temporal logic properties involving 
data, the current version of the tool does not support the data-based version 
of this language. It is well imaginable that this tool can be extended with our 
techniques. 

A different approach altogether is undertaken by e.g. Bryant et al. [7]. Their 
Counter arithmetie with Lambda expressions and Uninterpreted function (CLU) 
can be used to model both data and control, and is shown to be decidable. 
For this, CLU sacrifices expressiveness, as it is restricted to the quantifier-free 
fragment of first order logic. Moreover, their tool (UCLID) is restricted to dealing 
with safety properties only. We allow for safety, liveness and fairness properties to 
be verified automatically. Nevertheless, CLU is interesting as it provides evidence 
that there may be a fragment in our logic or in our specification language that 
is decidable, even for infinite state systems. 

Much work on symbolic reachability analysis of infinite state systems has 
been undertaken, but most of it concentrates on safety properties only. Bouaj- 
jani et al. (see e.g. [4]) describe how first-order arithmetical formulae, expressing 
safety and liveness conditions, can be verified over Parametric Extended Au- 
tomaton models, by specifying extra fairness conditions on the transitions of the 
models. The main difference with our approach is that we do not require fairness 
conditions on transitions of our models and that the first order modal /i-calculus 
is in fact capable of specifying fairness properties. 

The technique by Bultan et al. [8] seems to be able to produce results that 
are comparable to ours. Their techniques, however, are entirely different from 
ours. In fact, their approach is similar to the approach used by Alur et al. [1] for 
hybrid systems. It uses affine constraints on integer variables, logical connectives 
and quantifiers to symbolically encode transition relations and sets of states. The 
logic, used to specify the properties is a CTL-style logic. In order to guarantee 
termination, they introduce conservative approximation techniques that may 
yield “false negatives”, which always converges. It is interesting to investigate 
whether the same conservative approximation techniques can be adapted to our 
techniques. 

Summary. We discussed a pragmatic approach to verifying data-dependent sys- 
tems. The techniques and procedure we used, are based upon the techniques 
and algorithms, described by e.g. Mader [18]. A prototype tool implementation 
is described and a sample verification is discussed. Apart from the example from 
Section 7, the prototype was successfully applied to other systems, among others 
the Alternating Bit Protocol, see the discussion in [24] . 
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Summarising, we find that the verifications conducted with our prototype 
take in many cases an acceptable run-time, even though for systems with fi- 
nite state spaces, our prototype is often outperformed by most well-established 
tool-suites. However, we expect some improvements can still be made on the pro- 
totype. More importantly, we have been able to successfully use our prototype on 
systems with a finite (but extremely large) state-space, for which the standard 
/iCRL tool-suite (which is competitive with tool-suites that use explicit state- 
space representations) failed to calculate the exact state-space (see [24]). Since 
this is where current state-of-the-art technologies break down, our technique is 
clearly a welcome addition. 

Still, several other issues remain to be investigated. For instance, we think our 
technique may eventually be used to generalise specialised techniques, such as 
developed by Bryant et al. [7, 22]. Furthermore, in [15], we identify several results 
and techniques for solving equations and equation systems. In some cases, these 
would allow one to skip or speed up the approximation step in our procedure. A 
promising step is to implement those techniques and results and integrate them 
with the approach that is outlined in this paper. 

The prototype implementation also revealed a number of issues to be resolved. 
For instance, using our prototype, we were not able to prove absence of deadlock 
in the Bounded Retransmision Protocol [12], when the bound on the number 
of retransmissions is unknown. Finding effective work-arounds such problems is 
necessary to improve the overall efficacy of our technique. Here, the techniques 
and results of [15] may turn out to be of particular importance. 
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Abstract. The Abstract State Machine Langnage, AsmL, is a novel exe- 
cutable specification language based on the theory of Abstract State Ma- 
chines. AsmL is object-oriented, provides high-level mathematical data- 
structures, and is built around the notion of synchronous updates and 
finite choice. AsmL is fully integrated into the .NET framework and Mi- 
crosoft development tools. In this paper, we explain the design rationale 
of AsmL and sketch semantics for a kernel of the language. The details 
will appear in the full version of the paper. 



1 Introduction 

For years, formal method advocates have criticized specification and documenta- 
tion practices of the software industry. They point out that neither more rigorous 
English nor semi-formal notation like UML protect us from unintended ambigu- 
ity or missing important information. The more practical among them require 
specifications to be linked to an executable code. Without such a linkage one can- 
not debug the specification or impose it. Non- linked specifications tend quickly 
to become obsolete. 

We agree with the critique. We need specifications that are precise, readable 
and executable. The group of Foundations of Software Engineering at Microsoft 
Research [4] was not satisfied with existing solutions of the specification problem 
(we address related work in the full paper [8]) and has worked out a new solution 
based on the theory of abstract state machines [5, 6, 3, 9]. We think of specifica- 
tions as executable models that exhibit the desired behavior on the appropriate 
level of abstraction. Abstract State Machine Language, AsmL, is a language for 
writing such models [1]. 

The FSE group has designed AsmL, implemented it and integrated it with 
the Microsoft runtime and tool environment. Furthermore, the group has built 
various tools on top of AsmL. 



1.1 Language Features 

The language features of AsmL were chosen to give the user a familiar program- 
ming paradigm. For instance, AsmL supports classes and interfaces in the same 
way as or Java do. In fact all .NET structuring mechanisms are supported: 
enumerations, delegates, methods, events, properties and exceptions. Neverthe- 
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less, AsmL is primarily a specification language. Users familiar with the speci- 
fication language literature will find familiar data structures and features, like 
sets, sequences, maps, pattern matching, bounded quantification, and set com- 
prehension. 

But the crucial features of AsmL, intrinsic to ASMs, are massive synchronous 
parallelism and finite choice. These features give rise to a cleaner programming 
style than is possible with standard imperative programming languages. Syn- 
chronous parallelism means that AsmL has transactional semantics. (A single 
step of AsmL can be viewed as a transaction. This transaction may involve mas- 
sive parallelism.) This provides for a clean separation between the generation 
of new values and the committal of those values into the persistent state. For 
instance, when an exception is thrown, the state is automatically rolled back 
rather than being left in an unknown and possibly inconsistent state. Finite 
choice allows the specification of a range of behaviors permissible for an (even- 
tual) implementation. 

1.2 AsmL-S, a Core of AsmL 

AsmL is rich. It incorporates features needed for .NET integration and features 
needed to support the tools built on top of AsmL. AsmL-S represents the stable 
core of AsmL; the S alludes to “simple”. In this semantical study we allow 
ourselves to compactify the syntax and ignore some features that do not add 
semantical complexity. In particular, maps, sequences and sets are first-class 
citizens of the full AsmL. In AsmL-S only maps are first-class citizens. Sets of 
type t can be represented as maps from t to a unit type. 

Acknowledgments. Without the support from the FSE group this work would 
not be possible; particular thanks go to Wolfgang Grieskamp and Nikolai Till- 
mann for developing the runtime mechanism of AsmL. Thanks to Robert Stark 
for his comments on the draft of this extended abstract. 



2 AsmL-S Through Examples 

One can see AsmL as a fusion of the ASM paradigm and the .NET type system, 
influenced to an extent by other specification languages like VDM [2] or Z [15]. 
This makes it a powerful modeling tool. On the other hand, we also aimed for 
simplicity. That is why AsmL is designed in such a way that its core, AsmL- 
S, is small. AsmL-S is expression and object oriented. It supports synchronous 
parallelism, finite choice, sequential composition and exception handling. The 
rest of this section presents examples of AsmL-S programs and expressions. For 
the abstract syntax of AsmL-S, see Fig. 1 in Section 3. 

Remark 1. The definitions in this section are provisional, having been simplified 
for the purpose of explaining examples. The notions introduced here (stores, 
effects, evaluation, etc.) are, of course, defined formally in the full paper. 
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2.1 Expressions 

In AsmL-S, expressions are the only syntactic means for writing executable spec- 
ifications. Binding and function application are call-by-value. (The necessity of 
.NET integration is a good reason all by itself not to use lazy evaluation.) 

Literal is the set of literals, like 1, true, null or void. We write the value 
denoted by a literal as the literal itself. Literals are typed; for instance, 1 is of 
type Int and true is of type Bool. AsmL-S has various operations on Literal, like 
addition over integers or conjunction, i.e. and, over Bool. 

Exception is an infinite set of exceptions, that is disjoint from Literal. For 
now, think of exceptions as values representing different kinds of errors. We will 
discuss exceptions further in Section 2.8. 

If e is a closed expression, i.e. an expression without free variables, and is a 
literal or an exception, then e — > v means that e evaluates to v. The “v” above 
the arrow alludes to “value” . 

Examples 1-5 show how to evaluate simple AsmL-S expressions. 

Evaluation of Simple Expressions 



l-k2 


^ 3 


(1) 


1/0 - 


argX 


(2) 


let x 


= 1 do a; -f a; — ^ 2 


(3) 


let x 


= 1/0 do 2 — ^ argX 


(4) 


if true then 0 else 3 — ^ 0 


(5) 



For instance. Example 4 shows that let-expressions expose call-by- value se- 
mantics: if the evaluation of the binding fails (in this case, resulting in the argu- 
ment exception), then the complete let-expression fails, irrespective of whether 
the body is used the binding. 



2.2 Object Orientation 

AsmL-S encapsulates state and behavior in classes. As in C# or Java, classes 
form a hierarchy according to single inheritance. We use only the single dispatch 
of methods. Objects are dynamically allocated. Each object has a unique identity. 
Objects can be created, compared and passed around. 

OhjectLd is an infinite set of potential object identifiers, that is disjoint from 
Literal and Exception. Normal values are either object identifiers in OhjectLd or 
literals. Values are either normal values or exceptions. 

Nvalue = OhjectLd U Literal 
Value = Nvalue U Exception 

A type map is a partial function from OhjectLd to Type. It sends allocated 
objects to their runtime types. A location is an object identifier together with a 
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field name drawn from a set Fieldid. A content map is a partial function from 
Location to Nvalue. It records the initial bindings for all locations. 

TypeMap = Objectid Type 
Location = ObjectLd x FieldLd 
ContentMap = Location Nvalue 

If e is a closed expression, then e 0, w, v means that the evaluation of 

e produces the type map 9, the content map w and the value v. Examples 6-14 
demonstrate the object oriented features of AsmL-S. 

class A {} : new A() {oi-^-A},0,o (6) 

The execution of a nullary constructor returns a fresh object identifier o and 
extends the type map. The fresh object identifier o is mapped to the dynamic 
type of the object. 

class A {i as Lni}, class B extends A {b as Bool} : (7) 

new B{1, true) {oi-^B}, {(o, t) i— > 1, (o, 6) trae}, o 

The default constructor in AsmL-S takes one parameter for each field in 
the order of their declaration. The constructor extends the type map, extends 
the field map using the corresponding arguments, and returns a fresh object 
identifier. 

class A {i as Lnt} : new A{l).i — ^ 1 (8) 

Instance fields can immediately be accessed. 

class A [Faet{i as Lnt) as Lnt do (if i = 0 then 1 else i * me.Fact{n — 1))} : 
new A{). Fact (S) {oi— >A},0,6 (9) 

Method calls have call- by- value semantics. Methods can be recursive. Within 
methods the receiver object is denoted by me. 

class A {One{) as Lnt do 1, 

Two{) as Lnt do me.One{) + me.One{)}, (10) 

class B extends A { One 0 as /nt do —1} : new B{).Two{) — ^ —2 

As in or Java method, dispatch is dynamic. Accordingly, in this example, 
it is the redefined method that is used for evaluation. 

class A {i as Lnt} : (11) 

let X = (if 3 < 4 then null else new A(l)) do x.i — ^ nullX 
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If the receiver of a field or method selection is null, evaluation fails and throws 
a null pointer exception. 

class A {}, class B extends A {} : new B{) is A — ^ true (12) 

The operator is tests the dynamic type of the expression. 

class A {}, class B extends A {} : new B{) as A {o i— > B},0,o (13) 

Casting checks that an instance is a subtype of the given type, and if so then 
yields the instance without changing the dynamic type of the instance. 

class A {}, class B extends A {} : new A() as B — ^ castX (14) 

If casting fails, evaluation throws a cast exception. 



2.3 Maps 

Maps are finite partial functions. A map display is essentially the graph of the 
partial function. For example, a map display m={li— >2, 3i-^-4} represents the 
partial function that maps 1 to 2 and 3 to 4. The map m consists of two maplets 
1 1 -^ 2 and 3 4 mapping keys (or indices) 1, 3 to values 2, 4 respectively. 

Remark 2. In AsmL, maps can be also described by means of comprehension 
expressions. For example, {x ^ 2 * x | a; G {1,2,3}} denotes {1 2, 2 

4, 3 I— > 6}. In AsmL-S map comprehension should be programmed. 

The maps of AsmL-S are similar to associative arrays of AWK or Perl. Maps 
have identities and each key gives rise to a location. Arbitrary normal values can 
serve as keys. We extend the notion of a location accordingly. 

Location = Objectid x {Fieldid U Nvalue) 

Maps may be modified (see Section 2.4). Maps are often used in forall and 
choose expressions (see Sections 2.5 and 2.7). Examples 15-19 exhibit the use of 
maps in AsmL-S. 

new Int Bool {1 true, 5 i-^- false} (15) 

(o 1 -^- {Int Bool)}, |(o, 1) 1 -^- true, (o, 5) i-^- false}, o 

A map constructor takes the map type and the initial map as arguments. 

new Int —> Bool {1 i-^- true, 1 i— > false} — ^ argconsistencyX (16) 

If a map constructor is inconsistent (i.e. includes at least two maplets with 
identical keys but different values), then the evaluation throws an inconsistency 
exception. 

(new Int Bool {1 i-^- true}) [1] — ^ true (17) 
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The value of a key can be extracted by means of an index expression. 

(if true then null else new Int Int {1 7}) [1] — ^ nullX (18) 

(new Int Int {1 7}) [2] — ^ mapkeyX (19) 

However, if the receiver of the index expression is null or if the index is not in 
the domain of the map, then the evaluation throws a null exception or a map-key 
exception, respectively. 

Remark 3. AsmL-S treats maps differently than the full AsmL. The full AsmL 
is more sophisticated; it treats maps as values which requires partial updates [7]. 
In AsmL-S, maps are objects. An example illustrating this difference is given in 
Section 2.10. 

2.4 Assignments 

One of AsmL’s unique features is its handling of state. In sequential languages, 
like C# or Java, assignments trigger immediate state changes. In ASMs, and 
therefore also in AsmL, an assignment creates an update. An update is a pair: 
the first component describes the location to update, the second the value to 
which it should be updated. An update set is a set of updates. A triple that 
consists of a type map, a content map and an update set will be called a store. 

Update = Location x ( Value U {DEL}) 

UpdateSet = SetOf {Update) 

Store = TypeMap x ContentMap x UpdateSet 

Note that we extended V alue with a special symbol DEL which is used only 
with locations given by map keys and which marks keys to be removed from the 
map. 

If e is a closed expression, then e > s, v means that evaluation of e pro- 
duces the store s and the value v. Examples 20-23 show the three ways to create 
updates. Note that in AsmL-S, but not in AsmL, all fields and keys can be up- 
dated. AsmL distinguishes between constants and variables and allows updates 
only to the latter. 

class A {i as Int} : (20) 

newA(l).z:=2 > ({o i-^- A}, {(o, i) i-^- 1}, {((o, t), 2)}) , void 

A field assignment is expressed as usual. However, it does not change the 
state. Instead, it returns the proposed update. 

(new Int — > Bool {I true}) [2] := false (21) 

> ({o 1 -^- Int Bool}, {(o, I) 1 -^- true}, {((o, 2), false)}) , void 
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A map- value assignment behaves similarly. Note that the update set is created 
irrespective of whether the location exists or not. 

remove (new Int — > Bool {1 true}) [1] (22) 

({o Int — > Bool}, {((o, 1) true}, {(o, 1), DEL)}) , void 

The remove instruction deletes an entry from the map by generating an 
update that contains the placeholder DEL in the location to delete. 

class A {F{map as Int A, val as A) as Void do mop[0] := val}, 
class B extends A {} : (23) 

let a = new A() do a.F(new Int B {}, a) — ^ mapvalueX 

Since Int ^ B is a, subtype of Int A, it is reasonable that this piece of 
code type-checks successfully at compile time. However, the assignment fails at 
runtime and throws a map-assignment exception. Thus, map assignments must 
be type-checked at runtime. (The same reason forces runtime type-checks of 
array assignments in or Java.) 

2.5 Parallel Composition 

Hand in hand with the deferred update of the state goes the notion of syn- 
chronous parallelism. It allows the simultaneous generation of finitely many up- 
dates. Examples 24-27 show two ways to construct synchronous parallel updates 
in AsmL-S. 

let X = new Int Int {} do (x[2] := 4 || a;[3] := 9) (24) 

({oi-^ Int Int}, 0, {((o,2),4),((o,3),9)}), void 

Parallel expressions may create multiple updates. Update sets can be in- 
consistent. A consistency check is performed when a sequential composition of 
expressions is evaluated and at the end of the program. 

let X = new Int Int {} do 

let y = new Int Void {2 i-^- void, 3 i-^- void} do 

forall i in y do x[i] := 2 * i (25) 

> ({oi I— > Int Int, 02 Int Void}, 

{(o2,2) 1 -^ void,{o2,1>) ^ void}, {((oi, 2), 4), ((oi, 3), 9)}) , void 

Parallel assignments can also be performed using forall expressions. In a 
forall expression forall x in e\ do C 2 , the subexpression ei must evaluate to a 
map. The subexpression C 2 is then executed with all possible bindings of the 
introduced variable to the elements in the domain of the map. 

let X = new Int Int {} do (forall i in a: do x[i] := 1/i) (26) 

{%,%,%), void 
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If the range of a forall expression is empty, it simply returns the literal void. 

let X = new Int Int {2 4} do let y = a:[2] do ((a;[2] := 8) || y) (27) 

({o 1-^ Int Int},{{o,2) ^ 4}, {((o, 2), 8)}), 4 

Parallel expressions can return values. In full AsmL, the return value is distin- 
guished syntactically by writing return. In AsmL-S, the value of the second 
expression is returned, whereas forall-expressions return void. 

2.6 Sequential Composition 

AsmL-S also supports sequential composition. Not only does AsmL-S commit 
updates on the state, as in conventional imperative languages, but it also accu- 
mulates updates, so that the result of a sequential composition can be used in the 
context of a parallel update as well. Examples 28-31 demonstrate this important 
feature of AsmL-S. 

let X = new Int — > Int {2 i-^- 4} do ((a;[2] := 8) ; (x[2] := a;[2] * a;[2])) (28) 

> ({o 1-^- Int Int}, {(o, 2) i-^- 4)}, {((o, 2), 64)}) , void 

The evaluation of a sequential composition of e \ ; 62 at a state S proceeds as 
follows. First ei is evaluated at S. If no exception is thrown and the resulting 
update set is consistent, then the update set is fired (or executed) at S. This cre- 
ates an auxiliary state S' . Then 62 is evaluated at S' , after which S' is forgotten. 
The current state is still S. The accumulated update set consists of the updates 
generated by 62 at S' and the updates of e\ that have not been overridden by 
updates of 62. 

let X = new Int Int {2 i-^- 4} do (29) 

(x[2] := 8 II x\2] := 6) ; x[2] := x[2] * x[2] — ^ updateX 

If the update set of the first expression is inconsistent, then execution fails 
and throws an inconsistency exception. 

let X = new Int Int {1 1 -^ 2} do 

{x[2] := 4 II a;[3] := 6) ; x[3] := x[3] -f 1 (30) 

({01-^ Int Int}, {(0,1) 1-^ 2)1, {((0,2), 4), ((o,3),7)|), void 

In this example, the update ((o, 3), 6) from the first expression of the sequen- 
tial pair is overridden by the update ((o, 3), 7) from the second expression, which 
is evaluated in the state with content map {(o, 1) i-^- 2, (o, 2) i-^- 4, (o, 3) 1-^6}. 

let X = new Int Int {1 i-^- 3} do (while a;[l] >0 do x[l] := :r[l] - 1) (31) 

({o 1-^- Int Int}, {(o, 1) 1-^- 3)1, {((o, 1), 0)}) , void 

While loops behave as in usual sequential languages, except that a while loop 
may be executed in parallel with other expressions and the final update set is 
reported rather than executed. 
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2.7 Finite Choice 

AsmL-S supports choice between a pair of alternatives or among values in the 
domain of a map. The actual job of choosing a value from a given set X of 
alternatives is delegated to the environment. On the abstraction level of AsmL- 
S, an external function oneof(A) does the job. This is similar to delegating to 
the environment the duty of producing fresh object identifiers, by mean of an 
external function freshid(). 

Evaluation of a program, when convergent, returns one effect and one value. 
Depending on the environment, different evaluations of the same program may 
return different effects and values. Examples 32-36 demonstrate finite choice in 
AsmL-S. 



1|2 ^ oneof{l,2} (32) 

An expression e\ [ chooses between the given pair of alternatives. 

choose i in (new Int Void {1 void, 2 void}) do i 

> oneof I (({o Int Void}, {(o, 1) void, (o, 2) void}, 0), l) (33) 

(({o Int Void}, {(o, 1) void, (o, 2) void}, 0), 2) } 

Choice-expressions choose from among values in the domain of a map. 

choose i in (new Int Int {}) do i — ^ choiceX (34) 

If the choice domain is empty, a choice exception is thrown. (The full AsmL 

distinguishes between choose-expressions and choose-statements. The choose- 
expression throws an exception if the choice domain is empty, but the choose- 
statement with the empty choice domain is equivalent to void.) 

class Math{Double{x as Int) as Int do 2 * a;} : (35) 

new Math{) ,Double{l [ 2) — ^ oneof{2,4} 

class Math{Double{x as Int) as Int do 2 * a;} : (36) 

new Math{).Double{l) [ new Math {). Double (2) — ^ oneof{2,4} 

Finite choice distributes over function calls. 



2.8 Exception Handling 

Exception handling is mandatory for a modern specification language. In any 
case, it is necessary for AsmL because of the integration with .NET. The parallel 
execution of AsmL-S means that several exceptions can be thrown at once. 
Exception handling behaves as a finite choice for the specified caught exceptions. 
If an exception is caught, the store (including updates) computed by the try- 
expression is rolled back. 
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In AsmL-S, exceptions are special values similar to literals. For technical 
reasons, it is convenient to distinguish between literals and exceptions. Even 
though exceptions are values, an exception cannot serve as the content of a field, 
for example. (In the full AsmL, exceptions are instances of special exceptional 
classes.) There are several built-in exceptions: argX, updateX, choiceX , etc. In 
addition, one may use additional exception names e.g. fooX. 

class A {Fact(n as Int) as Int do (if n > 0 then 

(if n = 0 then 1 else Fact{n — 1)) else throw factorialX)} : (37) 
new A.Fact{—5) — ^ factorialX 

Custom exceptions may be generated by means of a throw-expression. Built- 
in exceptions may also be thrown. Here, for instance, throw argX could appro- 
priately replace throw factorialX . 

Examples 38-40 explain exception handling. 

let X = new Int Int {} do (try (a;[l] := 2 ; x[3] := 4/0) catch argX : 5) 
({o 1 -^- Int ^ /n<}, 0, 0), 5 (38) 

The argument exception triggered by 4/0 in the try-expression is caught, at 
which point the update ((x, 1),2) is abandoned and evaluation proceeds with 
the contingency expression 5. In general, the catch clause can involve a sequence 
of exceptions: a “catch” occurs if the try expression evaluates to any one of the 
enumerated exceptions. Since there are only finitely many built-in exceptions and 
finitely many custom exceptions used in a program, a catch clause can enumerate 
all exceptions. (This is common enough in practice to warrant its own syntactic 
shortcut, though we do not provide one in the present paper.) 

try (throw /ooA) catch harX ,hazX : 1 — ^ fooX (39) 

Uncaught exceptions propagate up. 

throw /ooA II throw barX — ^ oneof {fooX ,barX} (40) 

If multiple exceptions are thrown in parallel, one of them is returned nonde- 
terministically. 

throw fooX I 1 — ^ oneof {fooX , 1} (41) 

Finite choice is “demonic”. This means that if one of the alternatives of a 
choice expression throws an exception and the other one converges normally the 
result might be either that the exception is propagated or that the value of the 
normally terminating alternative is returned. 

2.9 Expressions with Free Variables 

Examples 1-41 illustrate operational semantics for closed expressions (containing 
no free variables). In general, an expression e contains free variables. In this case. 
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operational semantics of e is defined with respect to an evaluation context (6, r) 
consisting of a binding b for the free variables of e and a store r = (0, ui, u) where 
for each free variable x, b{x) is either a literal or a object identifier in dom(0). 
We write e b,r v if computation of e in evaluation context (6, r) produces 
value V. 

^ + y ^{x^7,y^ll}, (iSfifi) 18 (42) 

({oi— ^ Int—^ Bool}, {{o, 2) false}, (/)) falsC (43) 

A more general notation e > b,r s, v means that a computation of e in 
evaluation context (&, r) produces new store s and value v. 

2.10 Maps as Objects 

This subsection expands Remark 3. It was prompted by a question of Robert 
Stark who raised the following example. 

class A {/ as Int — > Bool, g as Int Bool} : 

let a = new A(new Int — > Bool {1 true, 2 true}, 

new Int Bool {}) do (44) 

a.g := a.f ; a.x( 2 ) := false 
({oi 1-^ A, 02 Int Bool, 03 Int Bool}, 

{(oi,/) 02, (01,5) 1-^ 03}, {((oi, 5),02), (02,2),/aZse)}), void 

In this example, the first assignment a.g := a.f is responsible for the update 
((oi, g), 02); the second assignment gives rise to the update {{02,2), false). Thus, 
a.g\ 2 ] has value false after all updates are executed. 

This same program has a different semantics in the full AsmL, where maps 
are treated as values rather than objects. In AsmL, the assignment a.g := a.f has 
the effect of updating a.g to the value of a.f, i.e., the map {1 true, 2 1-^ false}. 
The second assignment, a./[2] := false, has no bearing on a.g. Thus, a.g[ 2 ] has 
value true after all updates are executed. 

In treating maps as objects in AsmL-S, we avoid having to introduce the 
machinery of partial updates [7], which is necessary for the treatment of maps 
as values in AsmL. This causes a discrepancy between the semantics of AsmL-S 
and of AsmL. Fortunately, there is an easy AsmL-S expression that updates the 
value of a map mi to the value of another map m2 (without assigning m2 to 
mi): 



forall i in mi do remove mi[i] ; forall i in m 2 do mi[i] := m 2 [i] 

The first forall expression erases mi; the second forall expression copies m2 
to mi at all keys i in the domain of m2. 
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3 Syntax and Semantics 

The syntax of AsmL-S is similar to but different from that of the full AsmL. 
In this semantics paper, an attractive and user-friendly syntax is not a priority 
but brevity is. In particular, AsmL-S does not support the offside rule of the full 
AsmL that expresses scoping via indentation. Instead, AsmL-S uses parentheses 
and scope separators like 



3.1 Abstract Syntax 

We take some easy-to-understand liberties with vector notation. A vector x is 
typically a list of items possibly separated by commas. A sequence 

xiayi, . . . ,XnCtyn can be abbreviated to xay, where a represents a binary 
operator. This allows us, for instance, to describe an argument sequence as ti, 
...,£„ as tn more succinctly as 1 as t. The empty vector is denoted by e. 

Figure 1 describes the abstract syntax of AsmL-S. The met a- variables c, /, m, 
£, prim, op, lit, and exc, in Fig. 1 range over disjoint infinite sets of class names 
(including Object), field names, method names, local variable names (including 
me), primitive type symbols, operation symbols, literals, and exception names 
(including several built-in exceptions: argX , updateX , . . .) . Sequences of class 
names, field names, method names and parameter declarations are assumed to 
have no duplicates. 

An AsmL-S program is a list of class declarations, with distinct class names 
different from Object, followed by an expression, the body of the program. Each 
class declaration gives a super-class, a sequence of field declarations with distinct 
field names, and a sequence of method declarations with distinct method names. 

AsmL-S has three categories of types — primitive types, classes and map 
types — plus two auxiliary types. Null and Thrown. ( Thrown is used in the static 
semantics, although it is absent from the syntax.) Among the primitive types, 
there are Bool, Int and Void. (Ironically, the type Void isn’t void but contains 
a single literal void. That is how Void is in the C programming language and 
its relatives. We decided to stick to this tradition.) There could be additional 
primitive types; this makes no difference in the sequel. 

Objects come in two varieties: class instances and maps. Objects are created 
with the new operator only; more sophisticated object constructors have to be 
programmed in AsmL-S. A new-class-instance expression takes one argument 
for each field of the class, thereby initializing all fields with the given arguments. 
A new-map expression takes a (possibly empty) sequence of key-values pairs, 
called maplets, defining the initial map. Maps are always finite. A map can be 
overridden, extended or reduced (by removing some of its maplets). AsmL-S 
supports the usual object-oriented expressions for type testing and type casting. 

The common sequential programming languages have only one way to com- 
pose expressions, namely the sequential composition ci ; C2. To evaluate ci ; 62, 
first evaluate ci and then evaluate 62. AsmL-S provides two additional compo- 
sitions: the parallel composition ci || 62 and the nondeterministic composition 
Cl 1 62. To evaluate ei || 62, evaluate ei and 62 in parallel. To evaluate e\ [ 62 eval- 
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pgm = els : e 

els = class c extends c {fid mth} 
fid = f as t 

mth = mil as i) as t do e 
lit = null I void \ true | 0 | ... 

op = + \ - \ / \ = \ < \ and \ .. . 

prim = Bool \ Int \ Void \ ... 

t = prim I Null \ e \ t ^ t 

exe = argX \ updateX \ ehoieeX \ . . . 
e = 

lit I I 



op{e) 

let I = e do e 
if e then e else e 
new c (e) 

new t ^ t {e e} 
e.f I e[e] | e.m(e) 
e.f := e 

e[e] := e | remove e[e] 
e is t 
e as t 

e II e I forall f in e do e 
e 1 e I choose f in e do e 

e ; e | while e do e 
try e catch exe : e 
throw exe 



programs 

classes 

fields 

methods 

literals 

primitive operations 

primitive types 

normal types 

exceptions 

expressions 

literals/local variables 

built-in operations 

local binding 

case distinction 

creation of class instances 

creation of maps 

field/index/method access 

held update 

index update 

type test 

type cast 

parallel composition 
nondeterministic composition 
sequential composition 
exception handling 
explicit exception generation 



Fig. 1. Abstract Syntax of AsmL-S 



uate either ei or 62- The related semantical issues will be addressed later. The 
while, forall and choose expressions generalize the two-component sequential, 
parallel and nondeterministic compositions, respectively. 

AsmL-S supports exception handling. In full AsmL, exceptions are instances 
of special exception classes. In AsmL-S, exceptions are atomic values of type 
Thrown. (Alternatively, we could have introduced a whole hierarchy of exception 
types.) There are a handful of built-in exceptions, like argX; all of them end with 
“X”. A user may use additional exception names. There is no need to declare 
new exception names; just use them. Instead of prescribing a particular syntactic 
form to new exception names, we just presume that they are taken from a special 
infinite pool of potential exception names that is disjoint from other semantical 
domains of relevance. 
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3.2 Class Table and Subtypes 

It is convenient to view a program as a class table together with the expression 
to be evaluated [10]. The class table maps class names different from Object to 
the corresponding class definitions. The class table has the structure of a tree 
with edge relation c <l c' meaning that extends c' is in the declaration of c; we 
say c' is the parent of c. Object is of course the root of class tree. 

Remark j. Whenever the “extends c” clause is omitted in examples 1-43, there 
is an implicit extends Object. 

The subtype relation < corresponding to a given class table is generated 
recursively by the rules in Fig. 2, for arbitrary types t,t' ,t” , t,t' and classes 
c, c': 



• t < t, 



t<t' t' < t” 
t < t" 






c <1 c' 
c < c' 



< is a reflexive partial order 

< extends the parent relation over classes 



• t —> t' < Object 



maps are objects 



t < T t' < t' 

• (i ^ t') < (r ^ r') 



maps types are covariant in argument and result types 



t < Object 
Null < t 



Null lies beneath all object types 



• Thrown < t 



Thrown lies beneath all other types 



Fig. 2. Inductive Definition of the Subtype Relation 



Call two types comparable if one of them is a subtype of the other; otherwise 
call them incomparable. Primitive types compare the least. If t is a primitive 
type, then t < t and Thrown < t are the only subtype relations involving t. 

The following proposition is easy to check. 

Proposition 1. Every two types t\, t 2 have a greatest lower bound tiUt 2 . Every 
two subtypes of Object have a least upper bound U ^2 • □ 

Remark 5. One may argue that map types should be contravariant in the argu- 
ment, like function types [13]. In the full paper, we discuss pros and cons of such 
a decision. 

If c is a class different from Object, then addf{c) is the sequence of distinct 
field names given by the declaration of c. These are the new fields of c, acquired 
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in addition to those of parent{c). The sequence of all fields of a class is defined 
by induction using the concatenation operation. 

fldseq{Object) = e 

fldseq{c) = addf{c) • fldseq{parent{c)) 

We assume that addf{c) is disjoint from fids eq {parent (c)) for all classes c. If 
/ is a field of c of type t, then fldtype{f, c) = t. If fldseq{c) = (/i, . . . , fn) and 
fldtype{fi, c) = ti, then 

fldinfo{c) = f as t = {fi asti,..., fn as t„). 

The situation is slightly more complicated with methods because, unlike 
fields, methods can be overridden. Let addm{c) be the set of method names 
included in the declaration of c. We define inductively the set of all method 
names of a class. 



mthset{Object) = 0 

mthset{c) = addm{c) U mthset {parent {c)) 

For each m G mthset{c), dclr{m,c) is the declaration 
m{£i as Ti, ...,£„ as r„) as t do e 

of m employed by c. We assume, as a syntactic constraint, that the variables ^i 
are all distinct and different from me. The declaration dclr{m, c) is the declara- 
tion of TO in the class home{m, c) defined as follows: 

TO G addm{c) m G mthset{c) — addm{c) 

home{m,c) = c home{m,c) = home{parent{c)) 

In the sequel, we restrict attention to an arbitrary but fixed class table. 



3.3 Static Semantics 

We assume that every literal lit has a built-in type littype{lit) . For instance, 
littype{2) = Int, littype{true) = Bool and littype{null) = Null. We also assume 
that a type function optype{op) defines the argument and result types for every 
built-in operation op. For example, optype{and) = {Bool, Bool) Bool. 

Suppose e is an expression, possibly involving free variables. A type context 
for e is a total function T from the free variables of e to types. 

^t{s) is a partial function from expressions and type contexts to types. If 
^t{b) is defined, then e is said to be well-typed with respect to T, and ^t{s) is 
called its static type. 

The definition of Tt(c) is inductive, given by rules in Fig. 3. See the full 
paper for a more thorough exposition. 
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‘Xril'it) = littype{lit) 

optype{op) = f ^ t TT(e) < f 
%r{op{e)) = t 

Xr(ei) ^ t 

£ — ei do 62) = t>(e2) 

‘Xri^i) — Bool 

‘rr(if ei then 62 else 63) = Xr(e2) U ‘Ir(e3) 

fldinfo{c) — f as t ^t{&) < t 
XT(new c(e)) = c 

^T(e) ^ c 

‘^T(e./) fldtype{f,c) 

‘Iriei) %T{e2) < r 

dclr{m, c) = m(£ as r) as t do 63 
Xr(ei-m(e2)) = t 

X-r(e2) <XT(ei./) 

Xt(6i./ := C2) = 

Xr(ei) < Xr(e2) < ^2 
XT(new ^ t 2 > ^}) = ti ^ t 2 

Xt(£i) = T Xt( 62 ) < T 

XT(ei[e2]) — t 

XT(ei)^'T^^ Xt( 62 ) < T XtCgs) < t 

XT(ei[e2] := 63) = Void 

Xt(6i) = t Xr(e2) < r 

XT(remove ei[e2]) = Void 



XtW -T(^) 

t < Xt(6) 

Xr(e is t) = Bool 

t < Xr(e) 

Xt(c as t) = t 

Xr(ei) is defined 
XT(ei II 62) = Xr(e2) 

XT(ei) = r 

Xt@{£ H-»r}(e2) is defined 
Xr(forall £ in ei do 62) = Void 

Xt(6i 1 62) — XT(ei) U Xr{e2) 

XT(ei) = T ^ t 

XT(choose £ in ei do 62 ) = %TQ{t^T}{^ 2 ) 

Xr(ei) is defined 
Xr(ei ; 62 ) = Xt(c 2 ) 

XT(ei) — Bool XT(e2) is defined 
XT(while ei do 62) = Void 

Xt (throw exc) = Thrown 

XT(try ei catch exc : 62) = XT(ei) U %t{g2) 



Fig. 3. Static Types of Expressions in AsmL-S 



3.4 Well-Formedness 

We now make an additional assumption about the underlying class table: for 
each class c and each method m € mthset(c), m is well- formed relative to c 
(symbolically: m ok me). 

The definition of m ok in c is inductive. Suppose dclr(m,c) = m{£i as ti, 
. . . , as r„) as t do e and c <1 c'. Let T denote the type context {me 
c} U {fi 1 -^ Ti, . . . , T„}. 

TO G addm{c) — mthset{c') '^T(e) < t 
TO ok in c 

TO G mthset(c) — addm{c) to ok in d 



TO ok in c 
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m € addm(c) n mthset{c') ^ t m ok in c' 

ddr{m, c') = m{£i as r(, . . . , as t!^) as t' do e' f ^ t < f' ^ t' 

TO ok in c 

The statement f t < f' f , in the final premise, abbreviates the inequal- 

ities Ti < t[, . . . , Tn < and t < t' . 

3.5 Operational Semantics 

Suppose (b,r) is an evaluation context (Section 2.9) for an expression e, where 
r = {9,ui,u). Then (5, r) gives rise to a type context \h,r] defined by 

T 5 if &(^) G dom(0,) 

’ ylittype{b{i)) if b{£) G Literal. 

We say e is (b,r) -typed if it is well-typed with respect to the type context 
[b,r], that is, if ^[b^r]{e) is defined. 

In the full paper we define an operator over (6,r)-typed expressions. The 
computation of <Bb^r is in general nondeterministic (as it relies on external func- 
tions freshid and oneof) and it may diverge (as it is recursive but not necessarily 
well-founded). If it converges, it produces an effect (Sb,r(e) = (s,v) where s is a 
store and u is a value, that is, e y in notation of Section 2.9. 

After seeing the examples in Section 2, the reader should have a fairly good 
idea how the effect operator works. Figure 4 gives a few of the rules that comprise 
the definition of 2f,,r(e); each rule covers a different kind of expression e. See the 
full paper for a complete set of rules defining the effect operator. 



4 Analysis 

The effect operator is monotone with respect to stores: if <tb,r{e) = (s,u) then 
r is a substore of s. Furthermore, if v is an exception then r = s, meaning that 
the store is rolled back whenever an exception occurs. 

In addition to these properties, the static-type and effect operators satisfy 
the usual notions of type soundness and semantic refinement. See the full paper 
for precise statements and proofs of the theorems mentioned in this section. 
The type of an effect (s,u), where s = {9,uj,u), is defined as follows: 

{ 9{v) if u G dom(6*) 

littype{v) if u G Literal 
Thrown if u G Exception. 

Theorem 2 (Type Soundness). For every evaluation context {b,r) and every 
(b,r) -typed expression e, we have 

type{€b,r{e)) < ‘^[b,r]{e) 

for any converging computation of <^b,r{e). 
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&b,r{lit) = {r, lit) 

£i),r (e) = {s,v) op{v) is defined 

€b,r{op(e)) = (Us, op{v)) 

£6,r(ei) = {s,v) 



= {r,b(t)) 

^b,r{e) = (s, fi) op{v) is undefined 
£6,r(op(e)) = (r, argX) 

^b,r(ei) = (s, true) 



£6,r(let ^ = ei do 62) = ^b v}, s{e2) <£b,r-(if ei then 62 else 63) = £t,s(e2) 

£b,r(e) = {s,v) freshid() = o 
£6,,.(new c(e)) = (r U Us U ({o h-> c}, {o h-> {/ ^}}, 0 ), °) 

St,r(ei) = (si,ui) £6,r(e2)_= (^,^2) type{{si , Vi)) = c 
dclr[m, c) = m(^ as r) as t do 63 
£6,r(ei.m(e5)) = 

£t,r(ei) = (si,ui> &b,r{e2) = {S2,V2) Vi ^ null 
^b,r{ei-f := 62) = (si U S2 U ( 0 , 0 , {((ui, /), ^2)}) , void) 

/ <£6.r(el) = ^b,r(^) = (^,fi2> 

y consistent (vi,V2) freshid() = o 

£i,,r(new r ^ t {ef 1— > ^}) 

= (rU U^U ^ t)2}}. 0 ) I o) 

where consistent(ai, ...,a„,bi, = /\ («i = Q;) {bi = bj) 

1 <i,j <n 

<Et,r(er) = (X[,W[) £b,r(e2) = (^,02) consistent {yl,V2) 

£t,r(new T ^ t {el 1— > ej}) = (r, argconsistencyX) 

£(,,r(ei) = (s' ,v') 

gfcQ{^„p},y(e2) = (sp,Vp) for each p e dom(gjs>(u')) ^ 

£6,r(forall i in ei do 62) = U Sp, void') 

p^dom.{(jj^/ (v')) 

( ^b,r(ei) = (s',v') v' ^ Exception \ 

^bS){e^p},s'{e2) = (sp,Vp) for each p e dom(tjp (1;')) 

{vp : p £ dom(cns/(n'))} fl Exception / 0 J 
C:6,r(forall I in ei do 62) = 

{r, oneof((np : p 6 dom(a;s/ (u^))} n Exception)) 



Fig. 4. Examples of rules from the definition of &b,r(e) 



In the full paper we define a relation < of semantic refinement among ex- 
pressions. (More accurately, a relation <p is defined for each type context T.) 
The essential meaning of ei < 62 is that, for all evaluation contexts (6, r), 

~ computation of £b_r(ei) potentially diverges only if computation of €b_r.(e2) 
potentially diverges, and 

— the set of “core” effects of convergent computations of 6:b,r(ei) is included 
in the set of “core” effects of convergent computations of <Bb,r(s2)- 

Roughly speaking, the “core” of an effect (s,n) is the subeffect (s',v') that 
remains after a process of garbage-collection relative to the binding b: we remove 
all but the objects reachable from values in rng(6). 

The refinement relation < has the following property. 
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Theorem 3 (Refinement). Suppose e'g, eo, ei are expressions where eo is a subex- 
pression of Cl and Cq refines eg- Let e'-^ he the expression obtained from ci 
by substituting e'g in place of a particular occurrence of eg. Then e'^ refines 
ei- 

Here is a general example for refining binary choice expressions: 
eo ^ {true [ false) (if eg then ei else 62) ^ ei [ 62 
To give a similar general example involving the choose construct, we need a 

c. d . 

relation < of choice-domain refinement defined in the full paper. 



Proposition 4 



< 



ei 



(choose £ in ei do 62) < (choose £ in e( do 62) 



References 

1 . The AsmL webpage, http://research.microsoft.com/foundations/AsmL/. 

2. Dines Bjoerner and Cliff B. Jones (Editors), “Formal Specification and Software 
Development”, Prentice-Hall International, 1982. 

3. Egon Boerger and Robert Staerk, “Abstract State Machines: A Method for High- 
Level System Design and Analysis”, Springer, Berlin Heidelberg 2003. 

4. Foundations of Software Engineering group, Microsoft Research, 
http: / / research.microsoft.com / fse / 

5. Yuri Gurevich, “Evolving Algebra 1993: Lipari Guide”, in “Specification and Val- 
idation Methods”, Ed. E. Boerger, Oxford University Press, 1995, 9-36. 

6. Yuri Gurevich, “For every Sequential Algorithm there is an Equivalent Sequential 
Abstract State Machine”, ACM Transactions on Computational Logic 1:1 (2000), 
pages 77-111. 

7. Yuri Gurevich and Nikolai Tillmann, “Partial Updates: Exploration”, Springer J. 
of Universal Computer Science, vol. 7, no. 11 (2001), pages 918-952. 

8. Yuri Gurevich, Benjamin Rossman and Wolfram Schulte, “Semantic Essence of 
AsmL”, submitted for publication. A preliminary version appeared as Microsoft 
Research Technical Report MSR-TR-2004-27, March 2004. 

9. James K. Huggins, ASM Michigan web page, http://www.eecs.umich.edu/gasm. 

10. Atsushi Igarashi, Benjamin C. Pierce and Philip Wadler, “Featherweight Java: 
a minimal core calculus for Java and GJ”, ACM Transactions on Programming 
Languages and Systems (TOPLAS) 23:3 (May 2001), 396-450. 

11. Gilles Kahn, “Natural semantics”. In Proc. of the Symposium on Theoretical As- 
pects of Computer Science, Lecture Notes in Computer Science 247 (1987), 22- 
39. 

12. Robin Milner, Mads Tofte, Robert Harper, and David MacQueen, “The Definition 
of Standard ML (Revised)”, MIT Press, 1997. 

13. Benjamin C. Pierce, “Types and Programming Languages”, MIT Press, Cam- 
bridge, Massachusetts, 2002 




Semantic Essence of AsmL 



259 



14. Gordon D. Plotkin, “Structural approach to operational semantics”, Technical re- 
port DAIMI FN-19, Computer Science Department, Aarhus University, Denmark, 
September 1981 

15. J. M. Spivey, “The Z Notation: A Reference Manual” , Prentice-Hall, New York, 
Second Edition, 1992. 




An MDA Approach to Tame Component Based 
Software Development 



Jean-Marc Jezequel, Olivier Defour, and Noel Plouzeau 

IRISA - Universite de Rennes 1 
Campus universitaire de Beaulieu, Avenue du general Leclerc 
35042 Rennes Cedex, France 

{ j ean-marc . j ezequel , olivier . defour , noel . plouzeau}@irisa . f r 
http : / /www .irisa.fr/ triskell 



Abstract. The aim of this paper is to show how the Model Driven Architecture 
(MDA) can be used in relation with component based software engineering. A 
software component only exhibits its provided or required interfaces, hence de- 
fining basic contracts between components allowing one to properly wire them. 
These contractually specified interfaces should go well beyond mere syntactic 
aspects: they should also involve functional, synchronization and Quality of 
Service (QoS) aspects. In large, mission-critical component based systems, it is 
also particularly important to be able to explicitly relate the QoS contracts at- 
tached to provided interfaces with the QoS contracts obtained from required in- 
terfaces. We thus introduce a QoS contract model (called QoSCL for QoS Con- 
straint Language), allowing QoS contracts and their dependencies to be mod- 
eled in a UML2.0 modeling environment. Building on Model Driven Engineer- 
ing techniques, we then show how the very same QoSCL contracts can be ex- 
ploited for (1) validation of individual components, by automatically weaving 
contract monitoring code into the components; and (2) validation of a compo- 
nent assembly, including getting end-to-end QoS information inferred from in- 
dividual component contracts, by automatic translation to a Constraint Logic 
Programming language. We illustrate our approach with the example of a GPS 
(Global Positioning System) software component, from its functional and con- 
tractual specifications to its implementation in a .Net framework. 



1 Introduction 

Szyperski [22] remarked that while objects were good units for modular composition 
at development time, they were not so good for deployment time composition, and he 
formulated the now widely accepted definition of a software component: “a software 
component is a unit of composition with contractually specified interfaces and explicit 
context dependencies only. A software component can be deployed independently and 
is subject to composition by third-party'” . In this vision, any composite application is 
viewed as a particular configuration of components, selected at build-time and con- 
figured or re-configured at run-time, as in CORBA [15], or .NET [20]. 

A software component only exhibits its provided or required interfaces, hence de- 
fining basic contracts between components allowing one to properly wire them. 
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These contractually specified interfaces should go well beyond mere syntactic as- 
pects: they should also involve functional, synchronization and Quality of Service 
(QoS) aspects. In large, mission-critical component based systems, it is also particu- 
larly important to be able to explicitly relate the QoS contracts attached to provided 
interfaces with the QoS contracts obtained from required interfaces. 

It is then natural that people resorted to modelling to try to master this complexity. 
According to Jeff Rothenberg, '"Modeling, in the broadest sense, is the cost-ejfective 
use of something in place of something else for some cognitive purpose. It allows us 
to use something that is simpler, safer or cheaper than reality instead of reality for 
some purpose. A model represents reality for the given purpose; the model is an ab- 
straction of reality in the sense that it cannot represent all aspects of reality. This 
allows us to deal with the world in a simplified manner, avoiding the complexity, 
danger and irreversibility of reality.'” Usually in science, a model has a different na- 
ture that the thing it models. Only in software and in linguistics a model has the same 
nature as the thing it models. In software at least, this opens the possibility to auto- 
matically derive software from its model. This property is well known from any com- 
piler writer (and others), but it was recently be made quite popular with an OMG 
initiative called the Model Driven Architecture (MDA). 

The aim of this paper is to show how MDA can be used in relation with compo- 
nent based software engineering. We introduce a QoS contract model (called QoSCL 
for QoS Constraint Language), allowing QoS contracts and their dependencies to be 
modeled in a UML2.0 [13] modeling environment. Building on Model Driven Engi- 
neering techniques, we then show how the very same QoSCL contracts can be ex- 
ploited for (1) validation of individual components, by automatically weaving con- 
tract monitoring code into the components; and (2) validation of a component assem- 
bly, including getting end-to-end QoS information inferred from individual compo- 
nent contracts, by automatic translation to a Constraint Logic Programming. 

The rest of the paper is organized as follows. Using the example of a CPS (Global 
Positioning System) software component, Section 2 introduces the interest of model- 
ling components, their contracts and their dependencies, and describes the QoS Con- 
straint Language (QoSCL). Section 3 discusses the problem of validating individual 
components against their contracts, and proposes a solution based on automatically 
weaving reusable contract monitoring code into the components. Section 4 discusses 
the problem of validating a component assembly, including getting end-to-end QoS 
information inferred from individual component contracts by automatic translation to 
a Constraint Logic Programming. This is applied to the GPS system example, and 
experimental results are presented. Finally, Section 5 presents related works. 



2 The QoS Contracts Language 

2.1 Modeling Component-Based Systems 

In modelling techniques such as UML2.0 for example, a component is a behavioural 
abstraction of a concrete physical piece of code, called artifacts. A component has 
required and provided ports, which are typed by interfaces. These interfaces represent 
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the required and provided services implemented by the modelled artifact. The rela- 
tionship between the required and provided services within one component must be 
explicitly stated. The knowledge of this relationship is of utmost importance to the 
component-based application designer. In the rest of this section, we address this 
relationship using the example of a GPS device. 

A GPS device computes its current location from satellite signals. Each signal con- 
tains data which specifies the identity of the emiting satellite, the time of its emission, 
the orbital position of the satellite and so on. In the illustrating example, each satellite 
emits a new data stream every fifteen seconds. 

In order to compute its current location, the GPS device needs at least three signals 
from three different satellites. The number of received signals is unknown a priori, 
because obstacles might block the signal propagation. 

Our GPS device is modeled as a component which provides a getLocation( ) ser- 
vice, and requires a gelSignal( ) service from Satellites components. The GPS compo- 
nent is made up of four components: 

- the decoder which contains twelve satellite receivers (only three are shown on 
Fig. 1). This element receives the satellite streams and demutiplexes it in order to 
extract the data for each satellite. The number of effective data obtained via the 
getData( ) service depends not only on the number of powered receivers, but also 
on the number of received signals. Indeed, this number may change at any time. 

- The computer which computes the current location (getLocation( )) from the data 
(getDataO) and the current time (getTimeO). 

- The battery which provides the power (getPower()) to the computer and the de- 
coder. 

- The clock component which provides the current time (getTime()). 




Fig. 1. The GPS component-based model 

2.2 Contract Aware Components 

In component-based models, the services are usually specified at a syntactic level. 
This level of specification is not precise enough. Indeed, a service can be unavailable 
according to the state of the environment and, reciprocally, the environment can be 
modified by the execution of a service. 

Following [2] component contracts can be classified into four levels. The first level is 
the type compatibility. The second level adds pre/post-conditions: the operation’s be- 
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havior is specified by using Boolean assertions for each service offered, called pre and 
post-conditions, as well as class invariants [14]. The third level adds synchronization 
constraints and the fourth level provides extra-functional constraints. To be more pre- 
cise, we can build on the well-known idea of design-by-contract [12] negotiable con- 
tracts for components. These contracts ensure that a service will perform correctly. 

In the previous section 2.1, we have said that a dependency relationship always ex- 
ists inside one component between its provided and required services. A component 
provides its services inasmuch as its environment provides the services that it re- 
quires. All components always support this implicit contract. The extra-functional 
properties, which are intrinsic features of services, inherit this dependency relation- 
ship. The quality of a provided service depends on the quality of required services 
that it depends on. This fact is illustrated in our example. 

The GPS application contains several time out constraints. For instance, the pro- 
vided getLocation( ) service must ensure that it is completed in a delay less than 30s, 
whereas the getData( ) service must be completed in less than 25 s for example. 

However, it is obvious that the time spent to acquire data from the decoder, de- 
noted TethaD, has a direct impact on the global cost in time of the getLocation() 
service, denoted ThetaC. Not only ThetaC depends on ThetaD, but also on the num- 
ber of active receivers, denoted Nbr, because of the interpolation algorithm imple- 
mented by the Computer component. ThetaD and Nbr are two extra-functional prop- 
erties associated to the getData() service provided by the Decoder component. The 
relation that binds these three quantities is: 

ThetaC = ThetaD + Nbr* log ( Nbr ) . (1) 

Each receiver demultiplexes a signal, in order to extract the data. This operation 
has a fixed time cost: nearly 2 seconds. In addition, the demultiplexed signals must be 
transformed into a single data vector. This operation takes 3 s. If ThetaR (resp. 
ThetaS) denotes the time spent by the receiver to complete the getDatal() service 
(resp. the satellite to complete its getSignal() service), then we have the two follow- 
ing formulae: 

ThetaR = ThetaS + 2 , (2) 

ThetaD = max ( ThetaR) -t- 3 . ( 3 ) 

There exist many QoS contracts languages which allow the designer to specify the 
extra-functional properties and their constraints on the provided interfaces only (see 
section 5). However, none of them allow specifying dependency relationships be- 
tween the provided and required services of a component. To overcome this limita- 
tion we introduce the QoS Constraint Language (QoSCL). This language includes the 
fundamental QoS concepts defined in the well-known precursor QML [5]. It is the 
cornerstone to implement in a second time a QoS prediction tool. 

2.3 Extra-Functional Dependencies with QoSCL 

Our own contract model for extra-functional contracts extends the UML2.0 compo- 
nents metamodel. We designed the QoSCL notation with the following objectives in 
mind. 
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1. Since the extra-functional contracts are constraints on continuous values within 
multidimensional spaces, we wanted to keep the QML definitions of dimensions 
and contract spaces. 

2. Since our extra-functional contracts would he used on software components with 
explicit dependency specification, we needed means to express a provided con- 
tract in terms of required contracts. 

3. Since we targeted platform independent designs, we wanted to use the UML no- 
tation and its extension facilities. 

We thus designed our extra-functional contract notation as an extension of the 
component part of the UML2.0 metamodel: 

- Dimension: is a QoS property. This metaclass inherits the operation metaclass. 
According to our point of view, a QoS property is a valuable quantity and has to 
be concretely measured. Therefore we have chosen to specify a means of 
measurement rather than an abstract concept. Its parameters are used to specified 
the (optional) others dimensions on which it depends. The type of a Dimension is 
a totally ordered set, and it denotes its unit. The pre and post-conditions are used 
to specify constraints on the dimension itself, or its parameters. 

- ContractType: specializes Interface. It is a set of dimensions defining the contract 
supported by an operation. Like an interface, a ContractType is just a specifica- 
tion without implementation of its dimensions. 

- Contract: is a concrete implementation of a ContractType. The dimensions speci- 
fied in the ContractType are implemented inside the component using the aspect 
weaving techniques (see section 3). An isValid() operation checks if the contract 
is realized or not. 

- QoSComponent extends Component, and it has the same meaning. However, its 
ports provides not only required and provided interfaces which exhibit its func- 
tional behaviour, but also ContractTypes dedicated to its contractual behaviour. 



UML2.0 QoSCL 




Fig. 2. The QoSCL metamodel 
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With the QoSCL metamodel, it is possible to specify contracts, such as the Time- 
Out contract useful for our GPS, as an Interface in any UML case tool: 




Fig. 3. The TimeOut contract with QoSCL 

The QoSCL metamodel handles three specific aspects of contracts: dependency, 
composition, and adaptative behaviour. The dependency is the core of this work, and 
our main contribution to enhance existing extra-functional contracts specification 
languages, such as QML. QoSCL makes it also possible to model a composite 
contract via generalization association. At last, like any abstract functional model, it is 
possible to implement different behaviors for the same Operation, such as a Dimen- 
sion. Thus, the renegotiation of a contract can be implemented according to its 
environment. This behavior can be specified thanks the UML2.0 sequence diagrams, 
activity diagrams or state machine for instance. 



3 Implementing Contract- A ware Components 

QoSCL allows the expression of functional and extra-functional properties in a soft- 
ware component. The declared properties are useful to the software designer because 
this gives predictability to a component's behaviour. However, this predictability is 
valid only if the component implementation really has the behaviour declared by the 
component. This implementation validity is classical software validation problem, 
whatever the kind of contracts used [11]. 

These problems are usually addressed by two families of techniques. A first family 
is based on testing: the system under test is run in an environment that behaves as 
described in a test case. An oracle observes the behaviour of the system under test and 
then decides whether the behaviour is allowed by the specification. A second family 
of techniques relies on formal proof and reasoning on the composition of elementary 
operations. 

Standard software validation techniques deal with pre/post-condition contract 
types [12]. Protocol validation extends this to the synchronization contract types [8]. 
The rest of this section discusses issues of testing extra-functional property confor- 



mance. 
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3.1 Testing Extra Functional Behaviour 

Level 3 contracts (i.e. contracts that include protocols) are more difficult to test be- 
cause of non-determlnistic behaviours of parallel and distributed implementations. 
One of the most difficult problems is the consistent capture of data on the behaviour 
of the system's elements. Level 4 contracts {i.e. extra-functional properties) are also 
difficult to test for quite similar reasons. Our approach for testing level 4 contracts 
relies on the following features: 

- existence of probes and extra-functional data collection mechanisms (monitors); 

- test cases; 

- oracles on extra-functional properties. 

In order to be testable, a component must provide probe points where basic extra- 
functional data must be available. There are several techniques to implement such 
probe points and make performance data available to the test environment. 

1. The component runtime may include facilities to record performance data on 
various kinds of resources or events (e.g. disk operations, RPC calls, etc). Mod- 
ern operating systems and component frameworks now provide performance 
counters that can be “tuned” to monitor runtime activity and therefore deduce 
performance data on the component’s service. 

2. The implementation of the component may perform extra computation to monitor 
its own performance. This kind of “self monitoring” is often found in compo- 
nents that are designed as level 4 component from scratch (e.g. components pro- 
viding multimedia services). 

3. A component can be augmented with monitoring facilities by weaving a specific 
monitor piece of model or of code. Aspect-oriented design (AOD) or aspect- 
oriented programming can help in automating this extension. 

We have chosen this latter approach as our main technique for designing monitors. 
This choice was motivated mainly by the existence of “legacy” components from 
industrial partners [17]. From a software design process point of view, we consider 
that designing monitors is a specialist’s task. Monitors rely on low level mechanisms 
and/or on mechanisms that are highly platform dependant. By using aspect-oriented 
design (AOD), we separate the component implementation model into two main 
models: the service part that provides the component’s functional services under 
extra-functional contracts, and the monitor part that supervises performance issues. A 
designer in charge of the “service design model” does not need to master monitor 
design. A specific tool' (a model transformer) [24] is used to merge the monitor part 
of the component with its service part. 

More precisely, a contract monitor designer provides component designers with a 
reusable implementation of a monitor. This implementation contains two items: a 
monitor design model and a script for the model transformer tool (a weaver). The 
goal of this aspect weaver is to modify a platform specific component model by inte- 
grating new QoSCL classes and modifying existing class and their relationships. 



* The Kase tool is developed by TU-Berlin with the support of the European Project “Quality 
Control of Component-based Software” (QCCS) [17]. 
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3.2 A Practical Example of Weaving 

As we have said in the last paragraph of section 2, QoSCL allows us to model the 
structural, behavioral and contractual components features. These three aspects can be 
specified using the dedicated UML2.0 diagrams. The QoS aspect weaver is a mecha- 
nism integrated into Kase, which: 

- modifies the UML diagram (add new classes and associations) 

- modifies the behavior of the targeted service 

Thanks to QoSCL, it is possible to specify into Kase the contract types and their 
implementation such as TimeOut and TimeOutC (Fig. 4). According to our vision, 
detailed in the QoSCL section (§2.3), the TimeOut contract is an interface, which has 
a special operation denoting the “delay” dimension. The TimeOutC is a .Net class that 
implements the TimeOut interface. The value of the “delay” dimension is imple- 
mented like a private attribute {-delay: double) and its related access/evaluation 
method (delay(): double). 

A QoS aspect not only specifies how the structural diagram will be modified, but 
also how the monitored part and the monitor cooperate: when does the timer start, 
when does it stop, who handles timeout, etc... This part of the aspect is specified 
using the Hierarchical Message Sequence Charts (HMSC) notation in the UML 2.0. 
Fig. 5 shows the behavior of a contractual service, called op(), as a HMSC diagram. 
The opO operation is the service which must verify a TimeOut contract. The op_c() 
operation is a new operation, which realizes the op() service and evaluates the Time- 
Out contract below (Fig. 5). This service has two possible behaviors, depending on 
whether the op() service finishes before or after the timer. 




Fig. 4. TheTimeOut contract model for .Net 
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In addition of its structural (Fig. 4) and behavioral (Fig. 5) parts, a contractual QoS 
aspect has pre-conditions that must be met at weaving time. For example, a :Q class 
abides a TimeOut contract under the condition that it implements the op() service of 
course. In our tool, the aspect is concretely weaved in the UML diagram by a Python 
script, which: 

- checks the aspect pre-conditions; 

- weaves the aspect if these preconditions are satisfied, and this weaving adds new 
classes, modifies constructors and operations, etc). 

The QoS aspect weaver implemented in the Kase tool allows us to: 

- specify a QoS aspect; 

- implement an evaluation of this aspect for a targeted service. 

According to the QoSCL point of view, contracts can be specified at design time as 
specialized interfaces. Therefore, connecting two components at binding time is easy, 
using their respectively compliant required and provided interfaces. The QoS aspect 
weaver implemented in Kase allows to implement in C# any contract type. 

In case of failure, an extra-functional contract can be renegotiated. For instance, a 
time out contract that fails too often obviously needs to be adjusted (alternatively the 
service bound to that contract has to be shut down). 



°p_c() 



onTimeEvent () 




Fig. 5. Behavior of the op() service with evaluation of a TimeOut contract 
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3.3 Limitations of Extra-Functional Property Testing 

The QoSCL notation and the monitor integration technique help the component 
designer to define and check extra-functional properties. However, application 
designers rely on component assemblies to build applications. These designers 
need to estimate at design time the overall extra-functional properties of a given 
assembly. Using the techniques presented above, they can perform a kind of inte- 
gration testing. The tests aim at validating the extra-functional behavior of the 
assembly with respect to the global specification of the application. However, the 
application designers often have trouble to select and configure the components, 
make the assembly and match the global application behavior. Conversely, some 
applications are built with preconfigured components and the application designer 
needs to build a reasonable specification of the overall extra-functional behavior of 
the application. 



4 Predicting Extra-Functional Properties of an Assembly 

4.1 Modeling a QoS-Aware Component with QoSCL 

QoSCL is a metamodel extension dedicated to specify contracts whose extra- 
functional properties have explicit dependencies. Models can be used by aspect weav- 
ers in order to integrate the contractual evaluation and renegotiation into the compo- 
nents. However, at design time, it is possible to predict the global quality of the 
composite software. 

Predicting a behaviour is difficult. In the best cases, the behaviour can be proved 
but this. Otherwise, the behaviour is predicted with uncertainty. Since we want to 
predict the quality of a composite, i.e. la value of a set of extra-functional properties, 
this uncertainty will be translated into a numerical interval or an enumerated set of 
values, called validity domains. 

The dependencies defined in QoSCL, which bind the properties, are generally ex- 
pressed either as formulae or as rules. The quality of a service is defined as the extra- 
functional property’s membership of a specific validity domain. Predicting the global 
quality of a composite is equivalent to the propagation of the extra-functional validity 
domains through the dependencies. 

For instance, we have defined in section §2.2 a set of extra-functional properties 
that qualifies different services in our GPS component-based model. In addition, we 
have specified the dependencies between the extra-functional properties as formulae. 
This knowledge can be specified in QoSCL. The Fig. 6 below represents the computer 
component (Fig. 1) refined with contractual properties and their dependencies: 

The rules that govern the connection between two (functional) ports are also valid 
for ports with required or provided ContractTypes. Thus, a port that requires a service 
with its specific QoS properties can only be connected to another Port that provides 
this service with the same quality attributes. 
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Fig. 6. Quality attributes and dependencies specification of a component 

Specifying the QoS properties of required and provided services of a component is 
not enough to predict the quality of an assembly at design time. Additional informa- 
tion must be supplied: 

- constraints on the value of the QoS properties are needed to get the parties to nego- 
tiate and to agree; they explain the level of quality required or provided for a service 
by a component; 

- the dependency between these values is an important kind of relationship; it can 
be described either as with a function (for instance: ThetaC = ThetaD + Nbr * 
log( Nbr ) (1)) or with a rule (if Nbr = 3 and Bps = medium then ThetaC<25). 

In other words, these constraints can be stated as OCL [14] pre and post-conditions 
on the Dimensions. For instance: 

context Computer :: thetaC ( thetaD : real, nbr : int, 

P : real) : real 

pre: thetaD >= 0 and P >= 0 

post : result = thetaD + nbr * log ( nbr ) and P = 
3*nbr 

At design time, the global set of pre and post-conditions of all specified Dimen- 
sions of a component builds a system of non-linear constraints that must be satisfied. 
The Constraint Logic Programming is the general framework to solve such systems. 
Dedicated solvers will determine if a system is satisfied, and in this case the admissi- 
ble interval of values for each dimension stressed. 

4.2 Prediction of the GPS Quality of Service 

In this section we present the set of constraints for the GPS component-based model 
(Fig. 1). A first subset of constraints defines possible or impossible values for a QoS 
property. These admissible value sets come on the one hand from implementation or 
technological constraints and on the other hand from designers’ and users’ require- 
ments about a service. The fact that the Nbr value is 3, 5 or 12 (2), or ThetaC and 
ThetaD values must be real positive values (3-4) belongs to the first category of con- 
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straints. Conversely, the facts that Eps is at least medium (5) and P is less or equal 
than 15mW (6) are designers or users requirements. 

Nbr€ {3,5,12}, ( 2 ) 

ThetaC > 0, (3) 

ThetaD > 0, (4) 

Eps e (medium, high}, (5) 

P < 15. (6) 

Secondly, constraints can also explain the dependency relationships that bind the 
QoS properties of a component. For instance, the active power level P is linearly 
dependent on the Nbr number of receivers according to the formula: 

P = 3 * Nbr. (7) 

Moreover, the time spent by the getLocation() service {ThetaC) depends on the 

time spend by the getData() service {ThetaD) and the number of data received {Nbr), 
according the equation (1). Lastly, a rule binds the precision Eps, the time spent to 
compute the current position ThetaC and the number of received data {Nbr). The 
following diagram (Fig. 7) presents this rule: 



nbr 



12 



high 



medium 



iow 



high medium iow 



medium _ iow 



20 



25 



30 



35 



40 



45 



50 



Fig. 7. The rule that binds the Eps, Nbr and ThetaC dimensions 



All these constraints, expressed in OCL syntax, can be translated into a specific 
CLP-compliant language, using a Model Transfomation [24]. For instance, we pre- 
sent below the result of a such transformation applied to the computer QoSCompo- 
nent (Fig. 6) and its OCL conditions (using the Eclipse’’^’^ syntax): 



01 - 

02 - 

03- 

04- 

05- 

06- 

07- 

08- 

09- 

10 - 
11 - 
12 - 



computer ( [ ThetaC, Eps, P, ThetaD, Nbr ] ) :- 

ThetaC $>= 0, Eps = high, P $>= 0, 

ThetaD $>= 0, member] Nbr, [3,5,12]), 
ThetaC $>= 0, ThetaD $>= 0, 

ThetaC $= ThetaD + Nbr * log (Nbr), 

P $= Nbr * 3, 

rule ( Eps, ThetaC, Nbr). 

rule ( medium, ThetaC, 3) :- ThetaC $=< 25. 

rule ( low, ThetaC, 3) :- ThetaC $> 25. 

rule ( high, ThetaC, 5) :- ThetaC $=< 24. 

rule ( medium, ThetaC, 5) :- ThetaC $>24, 
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13- ThetaC $=< 30. 

14- rule ( low, ThetaC, 5) :- ThetaC $> 30. 

15- rule ( high, ThetaC, 12) :- ThetaC $=< 32. 

16- rule ( medium, ThetaC, 12) :- ThetaC $> 32, 

17- ThetaC $=<45. 

18- rule ( low, ThetaC, 12) :- ThetaC $> 45. 

The first line (01) indicates the QoS properties bound by the component. The two 
following lines (02, 03) are the constraints on the admissible values for these QoS 
properties, and lines 05 to 07 are the dependency relationships ( 1-7 and Fig. 7) that 
bind them. 

For each component, it is necessary to check its system of constraints, in order to 
compute its availability. The result of such request is the whole of admissible values 
for the QoS properties of the component. Thus, for the computer component, the 
solutions for the admissible QoS properties values are enumerated below: 



ThetaC 


ThetaD 


Eps 


P 


Nbr 


[3.49 .. 24.0] 


[0.0 .. 20.51] 


high 


15 


5 


[12.95 .. 32.0] 


[0.0 .. 19.05] 


high 


36 


12 



The requirement about the estimated position {Eps = high) implies that: 

- the number of data channels must be either 5 or 12, 

- consequently, the active power is either 15 or 36mW, 

- and the response times of the getLocationQ ands getDatai) services are respec- 
tively in the [3.49; 32.0] and [0.0; 20.51] real intervals. 

At this time, the designer knows the qualitative behavior of all of its components. 
It is also possible to know the qualitative behavior of an assembly, by conjunction of 
the constraints systems and unification of their QoS properties. 

The following constraint program shows the example of the GPS component: 



19- 


satellite ( [ ThetaS ] ) : - 






20- 


ThetaS $> 


= 15, ThetaS 


$ = < 


30 . 


21- 










22- 


battery] [ P ] 


) :- 






23- 


P $>= 0, 








24- 


P $=< 15. 








25- 










26- 


receiver] [ ThetaR, ThetaS 


] ) 


: - 


27- 


ThetaR $> 


= 0, ThetaS 


$> = 


0, 


28- 


ThetaR $= 


ThetaS + 2 . 






29- 










30- 


decoder] [ ThetaD, ThetaS, 


Nbr 


] ) :- 


31- 


ThetaD $> 


= 0, ThetaS 


$> = 


0, 


32- 


member] Nbr, [3,5,12] 


) , 




33- 


receiver ( 


[ ThetaR, ThetaS ] ) , 


34- 


ThetaD $= 


ThetaR + 3 . 






35- 










36- 


gps ] [ ThetaC, 


Eps, ThetaS 


] ) 


: - 


37- 


ThetaC $> 


= 0, Eps = high. 


ThetaS 
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38- computer! [ ThetaC, Eps, P, ThetaD, Nbr ] ), 

39- decoder! [ ThetaD, ThetaS, Nbr ] ), 

40- battery ! [ P ] ) . 

Similarly, the propagation of numerical constraints over the admissible sets of val- 
ues implies the following qualitative prediction behavior of the GPS assembly: 



ThetaC 


ThetaS 


Eps 


[23.49 .. 24.0] 


[15.0 .. 15.50] 


high 



The strong requirement on the precision of the computed location implies that the 
satellite signals have to be received by the GPS component with a delay less than 
15.5 s. In this case, the location will be computed in less than 24 s. 

5 Related Work 

In the Component-Based Software Engineering community, the concept of predict- 
ability is getting more and more attention, and is now underlined as a real need [4]. 
Thus, the Software Engineering Institute (SEI) promotes its Predictable Assembly 
from Certifiable Components (PACC) initiative: how component technology can be 
extended to achieve predictable assembly, enabling runtime behavior to be predicted 
from the properties of components. The ongoing work concentrates in a Prediction- 
Enabled Component Technology (PECT) as a method to integrate state-of-the-art 
techniques for reasoning about software quality attributes [23]. 

In the introduction of the SETs second workshop on predictable assembly [21], the 
authors note that component interfaces are not sufficiently descriptive. A syntax for 
defining and specifying quality of service attributes, called QML, is defined by Erol- 
und and Koistinen in [5], directly followed by Aagedal [1]. The Object Management 
Group (OMG) has developed its own UML profile for schedulability, performance 
and time specification [16]. These works emphasize the contractual use of QoS prop- 
erties, and constitute the fundamental core of QoS specifications. 

In the previous approaches, a QoS property is specified as a constant: they do not 
allow the specification of QoS properties dependency relationships. In contrast, 
Reussner proposes its parameterized contracts [18]: the set of available services pro- 
vided by a component depends on its required services that the context can provide. 
This concept is a generalization of the design-by-contract [11]. The same author has 
published in 2003 a recent extension of its work dedicated to the QoS [19]. He mod- 
els the QoS dependency with Markov chains where: 

- the states are services, with their QoS values; 

- the transitions represent the connections (calls) between components, i.e. the ar- 
chitecture of an assembly; 

- the usage profile of the assembly is modeled by probabilities for calls to a pro- 
vided service. Usage profiles are commonly modeled by Markov chains since 
Cheung [3] or Whittaker and Thomason [25]. 

From an assembly model and its usage profile, it seems possible to generate the as- 
sociated Markov chain and to predict the QoS level of provided services. Conversely, 
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it is not possible to invert the prediction process, in order to propagate a particular 
QoS requirement applied on a provided service on the QoS properties of required 
services that it depends. Moreover, via the Chapman-Kolmogorov equation, the 
Markov processes handle only probabilities, and they are not able to reason about 
formal un-valued variables. For instance, it is impossible to compare the n and 
M*log(n) complexity of two sort algorithms. 

Constraints solvers over real intervals and finite domains have already been used 
in the context of the software engineering. For instance, logic programming tech- 
niques can generate test cases for functional properties. More precisely, this technique 
allows a more realistic treatment of bound values [10]. About the software functional 
aspect, many authors have successfully used the constraints logic programming, 
based on translations from the source code to test or its formal specification into con- 
straints: the GATEL system [9] translates LUSTRE [7] expressions, and A. Gotlieb 
defines directly its transformation from C [6]. The works mentioned above focus on 
the functional aspects of software only, while our approach encompasses extra- 
functional properties. 



6 Conclusion and Future Work 

In mission-critical component based systems, it is particularly important to be able to 
explicitly relate the QoS contracts attached to provided interfaces of components with 
the QoS contracts obtained from their required interfaces. In this paper we have in- 
troduced a notation called QoSCL (defined as an add-on to the UML2.0 component 
model) to let the designer explicitly describe and manipulate these higher level con- 
tracts and their dependencies. We have shown how the very same QoSCL contracts 
can then be exploited for: 

1 validation of individual components, by automatically weaving contract monitor- 
ing code into the components; 

2 validation of a component assembly, including getting end-to-end QoS informa- 
tion inferred from individual component contracts, by automatic translation to a 
Constraint Logic Programming language. 

Both validation activities build on the model transformation framework developed 
at INRIA (cf. http://modelware.inria.fr). Preliminary implementations of these ideas 
have been prototyped in the context of the QCCS project (cf. http://www.qccs.org) 
for the weaving of contract monitoring code into components part, and on the Artist 
project (http://www.systemes-critiques.org/ARTIST) for the validation of a compo- 
nent assembly part. Both parts still need to be better integrated with UML2.0 model- 
ling environments, which is work in progress. 
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An Application of Stream Calculus to 
Signal Flow Graphs 



J.J.M.M. Rutten 
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1 Summary 

The present paper can be seen as an exercise in the author’s stream calculus 
[RutOl] and gives a new proof for an existing result about stream circuits. Such 
circuits are also known under the name of signal flow graphs, and are built from 
(scalar) multipliers, copiers (fan-out), adders (element-wise sum), and registers 
(here: one-element memory cells, aka delays) . Because of the presence of mem- 
ory, the input-output behaviour of these circuits is best described in terms of 
functions from streams to streams (of real numbers). The main statement of 
this paper (Theorem 6), gives a characterization of the input-output behaviour 
of finite stream circuits in terms of so-called rational streams. It is well-known 
in the world of signal processing, where it is formulated and proved in terms 
of the Z-transform (a discrete version of the Laplace transform) and transfer 
functions (see for instance [Lah98, p.694]). These transforms are used as repre- 
sentations of streams of (real or complex) numbers. As a consequence, one has 
to deal with two different worlds, and some care is required when moving from 
the one to the other. In contrast, we use stream calculus to formulate and obtain 
essentially the same result. What is somewhat different and new here is that we 
use only streams and nothing else. In particular, expressions for streams such as 

A )2 = (1) 2, 3, . . .), are not mere representations but should be read as formal 
identities. Technically, the formalism of stream calculus is simple, because it uses 
the constant stream X = (0, 1, 0, 0,0,.. .) as were it a formal variable (cf. work 
on formal power series such as [BR88]). 

We find it worthwhile to present this elementary treatment of signal flow 
graphs for a number of reasons: 

- It explains in very basic terms two fundamental phenomena in the theory of 
computation: memory (in the form of register or delay elements) and infinite 
behaviour (in the form of feedback) . 

- Although Theorem 6 is well-known to electrical engineers, computer scien- 
tists do not seem to know it. Also, the result as such is not so easy to isolate 
in the relevant literature on (discrete-time, linear) system theory. 

- Although not worked out here, there is a very close connection between The- 
orem 6, and a well-known result from theoretical computer science: Kleene’s 
theorem on rational (regular) languages and deterministic finite state au- 
tomata. 



F.S. de Boer et al. (Eds.): FMCO 2003, LNCS 3188, pp. 276-291, 2004. 
© Springer- Verlag Berlin Heidelberg 2004 
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- The present methodology is relevant for the area of component-based soft- 
ware engineering: it has recently been generalised to model software compo- 
sition by means of so-called component connectors, in terms of relations on 
the streams of ingoing and outgoing messages (or data elements) at the var- 
ious communication ports [AR03]. A similar remark applies to our ongoing 
work on stream-based models of sequential digital circuits. 

Stream calculus has been mainly developed as a playground for the use of 
coinduction definition and proof principles (see [RutOl]). In particular, streams 
and stream functions can be elegantly defined by so-called stream differential 
equations. For the elemenary operations on streams that are used in this paper 
(sum, convolution product and its inverse), the more traditional definitions of 
the necessary operations on streams suffice and therefore, coinduction is not 
discussed here. 

Acknowledgements. Thanks are due to the referees for their critical yet con- 
structive remarks. 



2 Basic Stream Calculus 

In this section, we study the set IR‘^ = {cr | ct : {0, 1, 2, . . .} ^ IR } of streams 
of real numbers. We shall introduce a number of constants and shall define 
the operations of sum, product, and inverse of streams. These constants and 
operations make of IR‘^ a calculus with many pleasant properties. In particular, 
it will be possible to compute solutions of linear systems of equations. 

We denote streams cr G IR“ by ct = (ao, cti, (T 2 , . . .). We define the sum a + t 
of cr, T G IR“ by 

a + T= {ao + To, CTi -k Ti, (72 + T2, . . .) 

(Note that we use the same symbol -I- for both the sum of two streams and 
the sum of two real numbers.) We define the convolution product cr x t by 



cr X T = (cto • To, (cTo • Ti) -f ((Ti • Tq), (cto • T2) -f (cti • Ti) -k ((J2 • Tq), . . .) 



That is, for any n > 0, 



(fj X ^ ( cr iz • Tn—k 

k=0 

In general, we shall simply say ‘product’ rather than ‘convolution product’. 
Note that we use the symbol x for the multiplication of streams and the symbol 
• for the multiplication of real numbers. Similar to the notation for the multipli- 
cation of real numbers (and functions), we shall write = 1 and cr”+^ = cr x cr". 
It will be convenient to define the operations of sum and product also for the 
combination of a real number r and a stream cr. This will allow us, for instance, 
to write 3 x ct for a + a + a. In order to define this formally, it will be convenient 
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to view real numbers as streams in the following manner. We define for every 
r G IR a stream [r] G IR“ by 

[r] = (r, 0,0,0,...) 

Note that this defines in fact a function 

[ ] : IR ^ ]R‘^, r^[r] 

which embeds the set of real numbers into the set of streams. This definition 
allows us to add and multiply real numbers r with streams a, yielding: 

[r]+(T= (r,0,0,0, ...) +cr 

= {r+(To, CTi, CT2, CT3 . . .) 

[r] X a = (r, 0,0,0,...) x a 

= (r • (To, r • (Ti, r • (72, . . .) 

For notational convenience, we shall usually write simply r + a for [r] + a, 
and similarly r x a for [r] x a. The context will always make clear whether 
the notation r has to be interpreted as the real number r of as the stream [r]. 
For multiplication, this difference is moreover made explicit by the use of two 
different symbols: r x a always denotes the multiplication of streams (and hence 
r should be read as the stream [r]) and r ■ s always denotes the multiplication 
of real numbers. We shall also use the following convention: 

— (T = [— 1 ] X (7 

= (~CT0; — CTl, — (72, . . .) 

Here are a few basic properties of our operators. 

Proposition 1. For all r, s G IR and a,r, p G IR“, 

[r] + [s] = [r + s] 

(7 + 0 = (7 
a + T = T + a 
a + {t + p) = {a + t) + p 
[r] X [s] = [r • s] 

0 X (7 = 0 

1 X (7 = (7 

a X T = T X a 

CT X (t + p) = (ct X r) + ((7 X p) 
a X {t X p) = {a X t) X p 

Particularly simple are those streams that from a certain point onwards are 
constant zero: 

cr= (ro,ri,r2 ,...,r„, 0 , 0 , 0, ...) 
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for n > 0 and tq, . . . ,r„ G IR. Using the following constant, we shall see that 
there is a very convenient way of denoting such streams: we define 

X = (0,1,0,0,0,...) 

It satisfies, for all r G IR, ct G IR‘^, and n > 0: 
r X X = (0, r, 0, 0, 0, . . .) 

X X a = (0,cro,CTi,(T2,...) 

X" = (0^_^,1,0,0,0,...) 

n times 

For instance, 2 + 3X — = (2, 3, 0, —8, 0, 0, 0, . . .). More generally, we have, 
for all n > 0 and all tq, . . . , r„ G IR: 

r 0 , + r iX + V 2 X^ + • • • + = (ro,ri,r2,...,r„,0,0,0, ...) 

Such streams are called polynomial streams. Note that although a polynomial 
stream such as 2 + 3X — 8X^ looks like a (polynomial) function f{x) = 2 + 3x — 
8a;^, for which a: is a variable, it really is a stream, built from constant streams 
(2, 3, 8, and X), and the operations of sum and product. At the same time, it 
is true that we can calculate with polynomial streams in precisely the same way 
as we are used to compute with (polynomial) functions, as is illustrated by the 
following example (here we use the basic properties of sum and product listed in 
Proposition 1): (2-X) + (l+3X) = 3+2X and (2-X) x (1+3X) = 2+5X-3A12. 

We shall need to solve linear equations in one unknown r, such as 

T = 1 + (X X r) (1) 

(where, recall, 1 = (1, 0, 0, 0, . . .)). Ideally, we would like to solve (1) by reasoning 
as follows: 



T = 1 + {X X r) 
r — (AT X r) = 1 
^ (1-A:) X T = 1 
1 



T = 



1-a: 



Recall that we are not dealing with functions but with streams. Therefore it 
is not immediately obvious what we mean by the ‘inverse’ of a stream 1 — X = 
(1,-1, 0,0,0,...). There is however the following fact: for any stream cr such 
that (To yf 0, there exists a unique stream t such that ct x t = 1. A proof of this 
fact can be given in various ways: 

(a) Using the definition of convolution product, one can easily derive the follow- 
ing recurrence relation 



Tn 



1 

CTO 



n—1 

^ ^ ^n—k * '^k 
k—0 



by which the elements of r can be constructed one by one. 
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(b) Alternatively and equivalently, one can use the algorithm of long division to 
obtain t out of a. 

(c) Our personal favourite is a method described in [RutOl], where we have 
introduced the operation of inverse by means of so-called stream differ- 
ential equations, formulated in terms of the notions of stream derivative 
a' = (<Ti, (72, (73, . . .) and initial value ctq for cr € IR“. (In fact, all the opera- 
tions on IR‘^ are there introduced by means of such equations.) 

Now we can simply define the inverse ^ of a stream a with ctq yf 0 as the 
unique stream r such that a xt = 1. Here are a few examples that can be easily 
computed using any of the methods (a)-(c) above: 



1 

1- A 
1 

1 - A2 
1 



( 1 , 1 , 1 ,...) 

( 1 , 0 , 1 , 0 , 1 , 0 ,...) 

(1,2,3,...) 



As with sum and product, we can calculate with the operation of inverse in 
the same way as we compute with functions: For all cr, t G IR“ with erg yf 0 yf tq. 



(7 X — = 1 
(7 

1 1 _ 1 
(7 T a X T 
1 



Using the various properties of our operators, it is straightforward to see that 
in the calculus of streams, we can solve linear equations as usual. Consider for 
instance the following system of equations: 



(7 = 1-1- {X X t) 
T = X X a 



In order to find a and r, we compute as follows: cr = 1 -|- (A x r) = 1 -I- (A x 
A X cr) = 1 -I- (A2 X cr). This implies cr — (A^ x cr) = 1 and (1 — A^) x cr = 1. 
Thus cr = and t = • 

We conclude this section with the following definition, which is of central 
importance for the formulation of the main result of this paper. 

Definition 2. The product of a polynomial stream and the inverse of a polyno- 
mial stream is called a rational stream. Equivalently, a stream a is rational if 
there exist n, m > 0 and coefficients ro, . . . ,r„, sq, ■ ■ ■ , Sm G IR with sg yf 0, such 
that 



rp + nA + raA" + ■ ■ ■ + r„A” 
Sg -t- S\X -\- S2A2 -t- • • • -t- SmX^ 



□ 
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3 Stream Circuits 

Certain functions from IR“ to IR‘^ can be represented by means of graphical 
networks that are built from a small number of basic ingredients. Such networks 
can be viewed as implementations of stream functions. We call them stream 
circuits; in the literature, they are also referred to as (signal) flow graphs. Using 
the basic stream calculus from Section 2, we shall give a formal but simple answer 
to the question precisely which stream functions can be implemented by such 
stream circuits. 

3.1 Basic Circuits 

The circuits that we are about to describe, will generally have a number of 
input ends and a number of output ends. Here is an example of a simple circuit, 
consisting of one input and one output end: 

I ^ 

The input end is denoted by the arrow shaft I and the output end is 

denoted by the arrow head ^ . For streams ct, r € IR“, we shall write 



a I ^ r 

and say that the circuit inputs the stream a and outputs the stream r. Writing 
the elements of these streams explicitly, this notation is equivalent to 

(cro,(Ti,Cr2,...) I ^ (to,Ti,T2,...) 

which better expresses the intended operational behaviour of the circuit: It con- 
sists of an infinite sequence of actions, at time moments 0,1,2,.... At each 
moment n > 0, the circuit simultaneously inputs the value cr„ G IR at its input 
end and outputs the value r„ G IR at its output end. In general, this value r„ 
depends both on the value and on the values ai that have been taken as 
inputs at earlier time moments i < n. Note that this implies that circuits have 
memory. 

Next we present the four basic types of circuits, out of which all other circuits 
in this section will be constructed. 

(a) For every a G IR, we define a circuit with one input and one output end, 
called an a-multiplier, for all a,r € IR“, by 

cr I a — s- T Tn = a • On, all n > 0 

T = a X a 

This circuit takes, at any moment n > 0, a value (j„ at its input end, multi- 
plies it with the constant a, and outputs the result t„ = a • (j„ at its output 
end. It defines, in other words, a function that assigns to an input stream a 
the output stream t = a x a. 
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Occasionally, it will be more convenient to write the multiplying factor a as 
a super- or subscript of the arrow: 






(b) The adder circuit has two input and one output ends, and is defined, for all 
a,T,p G IR“ by 



Pn = (^n + Tn, all n > 0 



T\^ p = a + T 

At moment n > 0, the adder simultaneously inputs the values cr„ and Tn at 
its input ends, and outputs their sum = cr„ -I- r„ at its output end. 

(c) The copier circuit has one input and two output ends and is defined, for all 
(J,T,p€ IR“, by 



<J h 



■P 



— Pn 



T = a = p 



all n > 0 



At any moment n > 0, the copier inputs the value (j„ at its input end, and 
outputs two identical copies r„ and at its output ends. 

(d) A register circuit has one input and one output end and is defined, for all 
cr, r G ]R“ , by 

a I — R — ^ T To = 0 and r„ = cr„_i, all n > 1 

r = (0, (To,cri,cr2,...) 

The register circuit can be viewed as consisting of a one-place memory cell 
that initially contains the value 0. The register starts its activity, at time 
moment 0, by outputting its value Tq = 0 at its output end, while it simulta- 
neously inputs the value uo at its input end, which is stored in the memory 
cell. At any future time moment n > 1, the value r„ = cr„_i is output and 
the value is input and stored. (For obvious resaons, the register circuit is 
sometimes also called a unit delay.) Recalling that for the constant stream 
X = (0, 1, 0, 0, 0, . . .), we have X x a = {0, aQ, ai,a 2 , ■ ■ ■), it follows that for 
all CT, T G IR“ , 

a I — R — ^ r T = X X a 



3.2 Circuit Composition 

We can construct a larger circuit out of two smaller ones by connecting output 
ends of the first to input ends of the second. For instance, for the composition 
of a 2-multiplier and a 3-multiplier, we shall write 
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We call the connection point o an (internal) node of the composed circuit. A 
computation step of this circuit, at any moment in time, consists of the simulta- 
neous occurrence of the following actions: a value is input at the input end of the 
2-register; it is multiplied by 2 and output at the output end of the 2-register; the 
result is input at the input end of the 3-register, is multiplied by 3 and is output 
at the output end of the 3-multiplier. More formally, and fortunately also more 
succinctly, we define the behaviour of the composed circuit, for all a,r € IR“, 
by 



-2 s- O I 3 — T 

a I 2^^ 3p I 3 — 

3p G IR“ : cr I 2- 



• P and P \ 



We shall consider all three of the above notations as equivalent. Combining 
the definitions of a 2- and 3-multiplier, we can in the above example easily 
compute how the output stream t depends on the input stream ct: 



G IR“ : 
G IR“ : 
r = 6 X cr 



a I 2 — ^ p and P I 3 — >■ r 

p = 2 X a and t = 3 x p 



Note that the stream p is uniquely determined by the stream a. The motiva- 
tion for our notation “3p” is not so much to suggest that there might be more 
possible candidate streams for p, but rather to emphasise the fact that in order 
to express the output stream r in terms of a, we have to compute the value of 
the stream p in the middle. 

We can compose circuits, more generally, with several output ends with cir- 
cuits having a corresponding number of input ends, as in the following example: 




c -I- 




In this example, the behaviour of the resulting circuit is defined, for all cr, r G 
IR", by 



cr h 




T 




r 
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37, <5 G IR“ : 



37, 5 G ]R‘^ 
T = 2 X a 





T 



cr = 7 = ^ and T = j + 6 



It will be convenient to have adders with more than two inputs and, sim- 
ilarly, copiers with more than two outputs. We define a ternary adder as the 
composition of two binary adders as follows: 




For input streams ct, t, p G IR‘^, it produces the output stream cr -|- r -I- p. We 
define a ternary copier by the following composition: 




It takes one input stream and produces three identical copies as output 
streams. Adders and copiers with four or more inputs and outputs can be con- 
structed in a similar fashion. 

The following circuit combines (various instances of) all four basic circuit 
types: 




C s- O I 3 s- O I O I 1- 




In order to express the output stream r for a given input stream a, we have 
to compute one intermediate stream for each of the (nine) internal nodes o in 
the circuit above. Using the definitions of the basic circuits, and computing from 
left to right, we find: 




CT I c ^ a I 3 ^ 3(7 I R — ^ 3Xa I 1 ^ t 
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(To save space, we have omitted the symbol x for multiplication.) We can 
now express the output stream r in terms of the input stream a as follows: 

r = (2 X cr) + (3A: X cr) + X cr) 

= (2 + 3X - IX^) X cr 

The circuit above computes — we shall also say implements — the following 
function on streams: 

/ : IR“ ^ IR“, /(cr) = (2 + 3X - IX^) x a 

If we supply the circuit with the input stream cr = 1 (= (1, 0, 0,0,.. .)) then 
the output stream is r = /(I) = 2 + iX — 7X'^. We call this the stream generated 
by the circuit. 

Convention 3. In order to reduce the size of the diagrams with which we depict 
stream circuits, it will often be convenient to leave the operations of copying and 
addition implicit. In this manner, we can, for instance, draw the circuit above 
as follows: 




The ( respective elements of the ) stream a gets copied along each of the three 
outgoing arrows. Similarly, the stream t will be equal to the sum of the output 
streams of the three incoming arrows. This convention saves a lot of writing. 
Moreover, if we want to express r in terms of a, we now have only three internal 
streams to compute. If a node has both incoming and outgoing arrows, such as 




then first the values of the output streams of the incoming arrows have to be 
added; then the resulting sum is copied and given as an input stream to each of 
the outgoing arrows. Consider for instance the circuit below. It has input streams 
a and t, an intermediate stream 7 , and output streams 6 and e in IR“.' 
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satisfying 

7 = 2cr + {X X t) 

6 = X xj 

= {2X X cr) + {X^ X r) 
e = 57 

= 10cr+ (5X X r) 

□ 

As an example, we compute the stream function implemented by the following 
circuit, with input stream a, output stream t, and intermediate streams 7 and 6: 



We have: 




7 = A X (T 

5 = (3 X cr) + (A^ X cr) 
r = (5 X 7) + (A X 6) 

= (8A + A^) X cr 

Thus the stream function implemented by this circuit is / : IR‘^ ^ 1R“ with 
/(cr) = (8A + A^) X cr, for all cr G IR‘^. An equivalent circuit, implementing the 
same stream stream function, is given by: 




The following proposition, of which we have omitted the easy proof, charac- 
terizes which stream functions can be implemented by the type of circuits that 
we have been considering so far. 

Proposition 4. For all n > 0 and rg, . . . ,r„ G IR, each of the following two 
circuits: 





o I — R- 



o o I — R- 

n times 
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implements the stream function f : IR“ ^ IR“ given, for all a € by 

f{a) = pxa 

where the stream p (generated by these circuits) is the polynomial 
P = fQ + TiX + r2X^ + ■ • • + ^ + rnX^ 

□ 



3.3 Circuits with Feedback Loops 

The use of feedback loops in stream circuits increases their expressive power 
substantially. We shall start with a elementary example and then give a simple 
and precise characterization of all stream functions that can be implemented by 
circuits with feedback loops. Consider the following circuit: 



O ^ R 1 O 




In spite of its simplicity, this circuit is already quite interesting. Before we 
give a formal computation of the stream function that this circuit implements, 
we give an informal description of its behaviour first. Assuming that we have 
an input stream a = (cto, CTi, (T 2 , ■ ■ •), we compute the respective elements of the 
output stream r = (tq, ri, T 2 , . . .). Recall that a register can be viewed as a 
one-place memory cell with initial value 0. At moment 0, our circuit begins its 
activity by inputting the first value cto at its input end. The present value of the 
register, 0, is added to this and the result tq = (Tq -I- 0 = o-q is the first value to be 
output. At the same time, this value uq is copied and stored as the new value of 
the register. The next step consists of inputting the value ai, adding the present 
value of the register, o-q, to it, and outputting the resulting value ti = ao + <Ji- 
At the same time, this value (Tq + is copied and stored as the new value of 
the register. The next step will input a 2 and output the value T 2 = cto + -I- (T 2 ■ 

And so on. We find: 



— (o’o,0’o-|-cri,(To + 0’l+0’2!---) 

Next we show how the same answer can be obtained, more formally and 
more systematically, by applying a bit of basic stream calculus. As before, we 
try to express the output stream r in terms of the input stream a by computing 
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the values of intermediate streams pi,p 2 , Ps G , corresponding to the three 
internal nodes of the circuit, such that 




Note that the values of Pi,P 2 ,P 3 are mutually dependent because of the 
presence of the feedback loop: ps depends on pi which depends on p 2 which 
depends on p^. The stream calculus developed in Section 2 is precisely fit to 
deal with this type of circularity. Unfolding the definitions of the basic circuits 
of which the above circuit is composed (one adder, one register, and one copier), 
we find the following system of equations: 



Pi — X X p2 

P3 = a + Pi 

P2 = P3 
T = P3 

We have seen in the previous section how to solve such systems of equations. 
The right way to start, which will work in general, is to compute first the output 
stream of the register: 



Pi — X X P2 
= X X P3 
= X X {a + pi) 

= {Xxa) + {Xx pi) 

This implies pi — {X x pi) = X x a, which is equivalent to pi = x a. 
As a consequence, r = p 3 = p 2 = o’ + pi = cr + ( x ct) = x a. Thus 
the stream function / : IR“ — > IR“ that is implemented by the feedback circuit 
is given, for all a G 1R“, by 



f{<^) 



1 

1-X 



X a 



We see that this function consists again of the convolution product of the 
argument a and a constant stream jzix- The main difference with the exam- 
ples in the previous subsections is that now this constant stream is no longer 
polynomial but rational. 

We still have to check that the first informal and the second formal compu- 
tation of the function implemented by the feedback circuit coincide. But this 
follows from the fact that, for all cr G IR“, 

1 



1- A 



X a = {ao,(To + (Ti,ao + (Ji + (J2,.. ■) 
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which is an immediate consequence of the definition of the convolution product 
and the fact that = (1) 1? 

Not every feedback loop gives rise to a circuit with a well-defined behaviour. 
Consider for instance the following circuit, with input stream a, output stream 
r, and internal streams pi,p 2 ,P 3 ' 

Pi ^ 1 1 P2 

T t 

cr I 1 ^ P3 I C ^ T 

In this circuit, we have replaced the register feedback loop of the example 
above by a 1-multiplier. If we try to compute the stream function of this circuit 
as before, we find the following system of equations: 



Pi = 1 X P2 

P3 = cr + Pi 
P2 = P3 
T = P3 

This leads to p 3 = cr -I- p 3 , which implies cr = 0. But a is supposed to be an 
arbitrary input stream, so this does not make sense. 

Problems like this can be avoided by assuming that circuits have the following 
property. 

Assumption 5. From now on, we shall consider only circuits in which every 
feedback loop passes through at least one register. □ 

Note that this condition is equivalent to requiring that the circuit has no 
infinite paths passing through only multipliers, adders, and copiers. 

Next we present the main result of the present paper. It is a characterization 
of which stream functions can be implemented by finite stream circuits. We 
formulate it for finite circuits that have one input and one output end, but it 
can be easily generalised to circuits with many inputs and outputs. 

Theorem 6. (a) Let C he any finite stream circuit, possibly containing feedback 
loops (that always pass through at least one register). The stream function 
f : IR‘^ ^ IR“ implemented by C is always of the form: 

/(cr) = pxa 

for all a € IR“ and for some fixed rational stream 



rp + nX + r 2 X^ -k ■ ■ ■ -k 
^0 SiJC -j- S2^^^ -f * * * -f Srti-^''^ 



with n,m > 0, rp, . . . , r^, sp, . . . , Sm G M, and sp yf 0. 
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(b) Let f : IR“ — > IR“ be a stream function of the form, for all a G IR“; 

/(cr) = px a 

for some fixed rational stream p. Then there exists a finite stream circuit C 
that implements f . 

Proof, (a) Consider a finite circuit C containing fc > 1 registers. We associate 
with the input end of C a stream cr and with the output end of C a stream r. 
With the output end of each register Ri, we associate a stream Oj. For the input 
end of each register Ri, we look at all incoming paths that: (i) start in either 
an output end of any of the registers or the input end of C, (ii) lead via adders, 
copiers, and multipliers, (iii) to the input end of Ri. Because of Assumption 5, 
there are only finitely many of such paths. This leads to an equation of the form 

ai = {al X X X a^) + • • • + (a^ x A x a^) + {oi x X x a) 

for some ai,a\ G IR. We have one such equation for each 1 <i <k. Solving this 
system of k equations in stream calculus as before, yields for each register an 
expression ai = pt x a, for some rational stream pi. Finally, we play the same 
game for r, at the output end of C, as we did for each of the registers. This will 
yield the following type of expression for r: 

r = (&i X ai) H h (6fe X ak) + {b x a) 

= {{bi X pi)-\ \- {bk X Pk) + b) X a 

for some b, bi G IR, which proves (a). For (b), we treat only the special case that 

_ ro + riA + r2A^ + 

I + S 1 A + 52^2 + 53^3 

where we have taken n = m = 3 and sq = 1. The general case is not more 
difficult, just more writing. We claim that the following circuit implements the 
function /(cr) = p x a (all a G IR“): 




where we have denoted input and output streams by a and t , and intermediate 
streams by Po, Pi, P2, Pd.- They satisfy the following equations: 

Po = CT - (si X pi) - (S 2 X P2) - (S 3 X ps) 

Pi = X X po 
P2 = X X Pi 
P3 = X X P2 

r = (ro X Po) + {ri x pi) + (r2 x P2) + {r^ x ps) 
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It follows that 

po = a — (siX X po) — X pq) — {s^X^ x po) 

As a consequence, we have, for i = 0, 1, 2, 3, that 



This implies 



~ 1 + siA: + 52^2 + s3^3 ^ 



ro + riX + T2X'^ + r^X^ 

T = TT TTTr X a 



1 + siA: + S2AT2 + S3AT3 

whereby the claim above is proved. □ 

Taking cr = 1 in Theorem 6 gives the following corollary. 

Corollary 7. A stream p G IR“ is rational if and only if it is generated by a 
(finite) stream circuit. □ 
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Abstract. Eormal methods, in particular model checking, are increas- 
ingly accepted as integral part of system development. With large soft- 
ware systems beyond the range of fully automatic verification, however, 
a combination of decomposition and abstraction techniques is needed. To 
model check components of a system, a standard approach is to close the 
component with an abstraction of its environment, as standard model 
checkers often do not handle open reactive systems directly. To make 
it useful in practice, the closing of the component should be automatic, 
both for data and for control abstraction. Specifically for model checking 
asynchronous open systems, external input queues should be removed, 
as they are a potential source of a combinatorial state explosion. 

In this paper we investigate a class of environmental processes for 
which the asynchronous communication scheme can safely be replaced by 
a synchronous one. Such a replacement is possible only if the environment 
is constructed under rather a severe restriction on the behavior, which 
can be partially softened via the use of a discrete-time semantics. We 
employ data-flow analysis to detect instances of variables and timers 
influenced by the data passing between the system and the environment. 

Keywords: formal methods, software model checking, abstraction, flow 
analysis, asynchronous communication, open components, program trans- 
formation 



1 Introduction 

Model checking [8] is well-accepted for the verification of reactive systems. To al- 
leviate the notorious state-space explosion problem, a host of techniques has been 
invented, including partial-order reduction [12,32] and abstraction [23,8,10]. 
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As standard model checkers, e.g., Spin [16], cannot handle open systems, one 
has to construct a closed model, and a problem of practical importance is how 
to close open systems. This is commonly done by adding an environment pro- 
cess that must exhibit at least all the behavior of the real environment. In the 
framework of the assume-guarantee paradigm, the environment should model the 
behavior corresponding to the verified properties of the components forming the 
environment. However, the way of closing should be well-considered to counter 
the state-space explosion problem. This is especially true in the context of model 
checking programs with an asynchronous message-passing communication model 
— - sending arbitrary message streams to the unbounded input queues would im- 
mediately lead to an infinite state space, unless some assumptions restricting the 
environment behavior are incorporated in the closing process. Even so, adding 
an environment process may result in a combinatorial explosion caused by all 
combinations of messages in the input queues. 

A desirable solution would be to construct an environment that communicates 
to the system synchronously. In [29] such an approach is considered for the sim- 
plest safe abstraction of the environment, the chaotically behaving environment: 
the outside chaos is embedded into the system’s processes, which corresponds 
to the synchronous communication scheme. Though useful at a first verification 
phase, the chaotic environment may be too general. Here, we investigate for what 
kind of processes, apart from the chaotic one, the asynchronous communication 
can be safely replaced with the synchronous one. To make such a replacement 
possible, the system should be not reactive — it should either only send or only 
receive messages. However, when we restrict our attention to systems with the 
discrete-time semantics like the ones of [15, 3], this requirement can be softened 
in that the restrictions are imposed on time slices instead of whole runs: In every 
time slice, the environmental process can either only receive messages, or it can 
both send and receive messages under condition that inputs do not change the 
state of the environment process. 

Another problem the closing must address is that the data carried with the 
messages are usually drawn from some infinite data domains. For data abstrac- 
tion, we combine the approaches from [29] and [17]. The main idea is to condense 
data exchanged with the environment into a single abstract value T to deal with 
the infinity of environmental data. We employ data-flow analysis to detect in- 
stances of chaotically influenced variables and timers and remove them. Based 
on the result of the data flow analysis, the system S is transformed into a closed 
system which shows more behavior in terms of traces than the original one. 
For formulas of next-free LTL [26,22], we thus get the desired property preser- 
vation: ii S'^ \= y} then S \= (p. 

The main target application are protocols specified in SDL {Specification and 
Description Language) [28]. As verification tool, we use the well-known Spin 
model checker. Our method is implemented as transformations of Promela- 
programs. Spin’s input language. With this tool we show experiments on a 
real-life protocol to estimate the effect of removing queues on the state space. 
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The rest of the paper is organized as follows. In Section 2 we fix syntax 
and semantics of the language. In Section 3 we describe under which condi- 
tion the asynchronous communication with the environment can be replaced by 
synchronous one. In Section 4 we abstract from the data exchanged with the 
environment and give a data-flow algorithm to optimize the system for model 
checking. In Section 5 we show some experimental results and in Section 6 we 
discuss related and future work. 



2 Semantics 

In this section we fix syntax and operational semantics we work with. Our model 
is based on asynchronously communicating state machines with top-level con- 
currency. The communication is done via channels and we assume a fixed set 
Chan of channel names for each program, with c^d , . . . as typical elements. The 
set of channel names is partitioned into input channels Chant and output chan- 
nels Chano, and we write ct, c'g, . . . to denote membership of a channel to one of 
these classes. A program Prog is given as the parallel composition UlLiPt of a 
finite number of processes. 

A process P is described by a tuple {in, out, Var, Loc, Edg,amit), where in 
and out are finite sets of input resp. output channel names of the process, Var 
denotes a finite set of variables, Loc denotes a finite set of locations or control 
states, and atnit is the initial state. We assume the sets of variables Vart of 
processes Pt in a program Prog = IltLiPi to be disjoint. An edge of the state 
machine describes a change of state by performing an action from a set Act] the 
set Edg C Loc x Act x Loc denotes the set of edges. For an edge (l,a, l) G Edg 
of P, we write more suggestively I — >a I- 

A mapping from variables to values is called a valuation; we denote the set 
of valuations by Val = Var D. We assume standard data domains such as 
N, Bool, etc., where we write D when leaving the data domain unspecified, and 
we silently assume all expressions to be well-typed. A location together with 
a valuation of process variables define a state of a process. The set of process 
states is defined as A = Loc x Val, and each process has one designated initial 

state CTtnit — {linit : ’dinit') ■ 

Processes communicate by exchanging signals (carrying values) over chan- 
nels. Signals coming from the environment form the set of external signals Sig 
Signals that participate in the communication within the system belong to the 
set Sigtnt of internal signals. Note that both signal sets are not necessarily dis- 
joint. 

As untimed actions, we distinguish (1) input over a channel c of a signal s 
containing a value to be assigned to a local variable, (2) sending over a channel c 
a signal s together with a value described by an expression, and (3) assignments. 
We assume the inputs to be unguarded, while output and assignment are guarded 
by a boolean expression g, its guard. The three classes of actions are written as 
cls{x), g [> c!s(e), and g\> x := e, respectively, and we use a, a' . . . when leaving 
an action unspecified. 
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Table 1. Step semantics for one process 



I ^c?s(x) ^ ^ ^ ^C?s(x) ^ ^ ^ 7“ ^ T-^ 

■ Input Discard 



I — >9>c!(s,e) i e Edg = trwe [ef^ = u 

i^^v) ^Co!(s,'i;) ihv) 

I — >g>x:=e I € Edg = tru6 |e]r, = V 

(l,v) {l,ri[x^v]) 

I — >g I> set t:=e 1 & Edg = truB [c]^ = u 

i ^ jV ) ~*'T (i, I?[i oji(d)]) 

I — >g > reset t I € Edg = truB 



Output 



Assign 



Set 



Timeout 



(1,V) {l,ri[t^°ff]) 

I >g^ [> reset t ^ Edg [fj^? ~ OTt(0') 

(i,v) 

{I — >c I € Edg ^ a ^ gti> rBSBt t) [t]^ = on(0) 



bloBkBdip) 

Reset Tickp 



n ^tick cr[tH^(t-i)] 



TDiscard 



Time aspects of a system behavior are specified by actions dealing with 
timers. Each process has a finite set of timer variables (with typical elements 
A timer can be either set to a value, i.e., activated to run for the 
designated period, or reset, i.e., deactivated, which corresponds to timer values 
on{n), off , respectively. Setting and resetting are expressed by guarded actions 
of the form g t> set t := e and g \> reset t. If a timer expires, i.e., the value of a 
timer becomes zero, it can cause a timeout, upon which the timer is reset. The 
timeout action is denoted by gt \> reset t, where the timer guard gt expresses the 
fact that the action can only be taken upon expiration. 

The behavior of a single process is then given by sequences of states atnit = 
CTo CTi • ■ • starting from the initial one. The step semantics is given as a 
labelled transition relation — C if x Lab x S between states. The set of labels 
Lab is formed by r-labels for internal steps, tzcfc-labels for time progression and 
communication labels. Communication label, either input or output are of the 
form cl{s,v) resp. c!(s,u). Depending on the location, the valuation, and the 
potential next actions, the possible successor states are given by the rules of 
Table 1. 

Inputting a signal with a value via a channel means reading a value belonging 
to a matching signal from the channel and updating the local valuation accord- 
ingly (cf. rule Input), where rj[x^v] stands for the valuation equaling rj for all 
y G Var except for x G Var, where r][x^v]{x) = v holds instead. A specific 
feature commonly used for communicating finite state machines (e.g. in SDL- 




296 



N. loustinova, N. Sidorova, and M. Steffen 



92 [27]) is captured by rule Discard: If the input value cannot be reacted upon 
at the current control state, i.e., if there is no input action originating from the 
location treating this signal, then the message is just discarded, leaving control 
state and valuation unchanged. The automaton is therefore input-enabled: it 
cannot refuse to accept a message; it may throw it away, though. 

Unlike inputs, outputs are guarded, so sending a message involves evaluat- 
ing the guard and the expression according to the current valuation (cf. rule 
Output). Assignment in Assign works analogously, except that the step is in- 
ternal. We assume for the non-timer guards, that at least one of them evaluates 
to true in each state. At the SDL source language, this assumption corresponds 
to the natural requirement that each conditional construct must cover all cases, 
for instance by having at least a default branch. The system should not block 
because of a non-covered alternative in a decision-construct [25]. 

Concerning the temporal behavior, timers are treated in valuations as vari- 
ables, distinguishing active and deactivated timer. We use ojf to represent in- 
active timers. The value of an active timer shows the delay left until timer 
expiration. The set-command activates a timer, setting its value to the specified 
period until timer expiration, and reset deactivates the timer. Both actions are 
guarded (cf. rules Set and Reset). A timeout may occur, if an active timer has 
expired, i.e., reached zero (cf. rule Timeout). 

Time elapses by counting down active timers till zero, which happens in case 
no untimed actions are possible. In rule TiCKp, this is expressed by the predicate 
Mocked on states: Uocked{a) holds if no move is possible except either a tick- 
step or a reception of a message, i.e., if a for some label A, then A = tick or 
A = c?(s, v). In other words, the time-elapsing steps are those with least priority. 
The counting down of the timers is written by which we mean, all 

currently active timers are decreased by one, i.e., on{n -|- 1) — 1 = on(n), non- 
active timers are not affected. Note that the operation is undefined for on(0), 
which is justified later by Lemma 1. 

In SDL, timeouts are often considered as specific timeout messages kept in 
a queue like any other message, and timer-expiration consequently is seen as 
adding a timeout-message to the queue. We use an equivalent presentation of 
this semantics, where timeouts are not put into the input queue, but are modelled 
more directly by guards. The equivalence of timeouts-by-guards and timeouts-as- 
messages in the presence of SDL’s asynchronous communication model is argued 
for in [3] . The time semantics for SDL chosen here is not the only one conceivable 
(see e.g. [6] for a broader discussion of the use of timers in SDL). The semantics 
we use is the one described in [15, 3], and is also implemented in DTSpin [2, 11], 
a discrete time extension of the Spin model checker. 

In the asynchronous communication model, a process receives messages via 
channels modelled as queues. We write e for the empty queue; (s,v) :: q denotes 
a queue with message (s,v) at the head of the queue, i.e., (s,v) is the message 
to be input next; likewise the queue q::{s,v) contains (s,v) most recently en- 
tered; Q denotes the set of possible queues. We model the queues implementing 
asynchronous channels explicitly as separate entities of the form {c,q), consist- 
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ing of the channel name together with its queue content. We sometimes refer to 
the channel process (c, q) just by its name c. We require for the input and the 
output channel names of channel c to be m(c) = Cq and out{c) = Ci resp. The 
operational rules for queues are shown in Table 2. 

In analogy to the tick-steps for processes, a queue can perform a tick-step iff 
the only steps possible are input or tick-steps, as captured again by the hlocked- 
predicate (cf. rule Tick). Note that a queue is blocked and can therefore tick 
only if it is empty, and that a queue does not contain any timers. Hence, the 
counting down operation has no effect and is therefore omitted in the 

rule Tickq of Table 2. 



Table 2. Step semantics for a channel c 



In 

(c,q) ^co?(s,v) (c,q::{s,v)) 

Out 

(c, (s,w) ::q) (c,q) 



blocked{c, q) 

Tickq 

(c, q) ^tick (c, q) 



A global semantics of a system S is given by a parallel composition of labelled 
transition systems modelling processes and channels of the specification. The 
semantics of the parallel composition S' = 5*1 || . . . || S'n is given by the rules of 
Table 3, where ext{S) is used to denote the set of external channel names. Since 
we assumed the variable sets of the components to be disjoint, the combined 
state is defined as the product. We write for the value Isjai of x, for one 



Table 3. Parallel composition 



Ci ic!(s,'i;) tti (Jj ^c?(s,v) Hj i ^ j 

i i ^ Comm 

(. . . , fJi, . . . , fjj, . . .) (. . . , d*, . . . , fjj, . . .) 

1 ^ tick (J \ • • • (y ri ^ tick ^ n 

Tick 

(CTI , . . . , (Jfi^ ^tick (ci, . . . ,<T„) 

(Ti ^c?(s,d) ^i C ^ CXt(^S^ 

iNTERLEAVEin 

(. . . , iTj, . . .) ^c?(s,ti) {•••■! • • •) 

(7 i ^c!(s,v) ^ ^ SXtl^S'^ 

iNTERLEAVEo^it 

(. . . , (Ti, . . .) ^c!(s,u) (• • • 5 • • •) 

O' i ^ 7 - Oi 

InTERLEAVEt 

(. . . , <Ti, . . .) (• • • ; • • •) 
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state Gi being part of ct; analogously, we use the notation \e\a for the value of 
e in cr. The initial state of a parallel composition is given by the array of initial 
process states together with (c, e) for channels in Chan. We call a sequence 
Cmit = CTo CTi ^A • ■ • starting from an initial state a run. 

Communication between two processes is done by exchanging a common sig- 
nal and a value over a channel. According to the syntactic restriction on the use 
of communication labels, only synchronisation between a process and a chan- 
nel may happen. Sending of a signal over the channel means synchronising an 
output step of the process with an input step of the queue, i.e. a Co!(s,v) step 
of the process is synchronised with a Co?(s,u) step of the channel c. Receiving 
is accomplished by synchronising an output step, which removes first element 
from the channel queue, with an input step of the process. As defined by the 
rule Comm of Table 3, systems perform common steps synchronously. The result 
of communication is relabelled to r. 

Communication steps of two partners may synchronize, if they use the same 
channel name. Communication steps may be interleaved as in rules lNTERLEAVEi„ 
and iNTERLEAVEotit provided the channel name belongs to the set of external 
channel names ext{S) of the system. As far as r steps are concerned, each system 
can act on its own according to rule Interleave,-. 

Lemma 1. Let S he a system and a & E one of its states. 

1. If a ^tick then |t]o- yf on(0), for all timers t. 

2. If a ^tick , then for all channel states (c, q), q = e. 

Proof. For part (1), if = on(0) for a timer t in a process P, then a r-step is 
allowed due to either Timeout or TDiscard of Table 1. Hence, the system is 
not blocked and therefore cannot do a tick-step. 

Part (2) follows from the fact that a channel can only perform a tick-step 
exactly when it is empty. □ 

The following lemma expresses that the blocked predicate is compositional 
in the sense that the parallel composition of processes is blocked iff each process 
is blocked (cf. rule Tick of Table 3) . 

Lemma 2. For a state a = (ui, . . . , cr„) of a system S, hlocked{a) iff hlocked{ai) 
for all Gi. 

Proof. If G is not blocked, it can perform a r-step or an output-step. The output 
step must originate from a process, which thus is not blocked. The r-step is 
either caused by a single process or by a synchronizing action of a sender and 
a receiver; in both cases at least one process is not blocked. For the reverse 
direction, a r-step of a single process being thus not blocked, entails that g is 
not blocked. An output step of a single process causes g either to do the same 
output step or, in case of internal communication, to do a r-step. In both cases, 
G is not blocked. □ 
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3 Replacing Asynchronous with Synchronous 
Communication 

In a system with asynchronous communication, introducing an environment pro- 
cess can lead to a combinatorial explosion caused by all combinations of messages 
in the queues modelling channels. An ideal solution from the perspective of the 
state space would be to construct an environment process that communicates 
with the system synchronously. In this section, we specify under which condi- 
tions we can safely replace the asynchronous communication with an outside 
environment process, say E, by synchronous communication. 

A general condition an asynchronously communicating process satisfies is that 
the process is always willing to accept messages, since the queues are unbounded. 
Hence, the environment process must be at least input enabled: it must always 
be able to receive messages, lest the synchronous composition will lead to more 
blockings. Thanks to the DiSCARD-rule of Table 1, SDL-processes are input 
enabled, i.e., at least input-discard steps are possible, which throw away the 
message and do not change the state of the process. Another effect of an input 
queue is that the queue introduces an arbitrary delay between the reception of 
a message and the future reaction of the receiving process to this message. For 
an output, the effect is converse. This means, that in order not to miss any 
potential behavior, the asynchronous process can be replaced by the analogous 
synchronous process as long as there are either only input actions or else only 
output actions, so the process is not reactive.^ This is related to the so-called 
Brock- Ackerman anomaly, characterizing the difference between buffered and 
unbuffered communication [7]. 

Disallowing reactive behavior is clearly a severe restriction and only mod- 
erately generalizes completely chaotic behavior. One feature of the timed se- 
mantics, though, allows to loosen this restriction. Time progresses by tick-steps 
when the system is blocked. This especially means that when a tick happens, all 
queues of a system are empty (cf. Lemma 1). This implies that the restrictions 
need to apply only per time slice, i.e., to the steps between two ticks, ^ and not 
to the overall process behavior. Additionally we require that there are no infinite 
sequences of steps without a tick, i.e., there are no runs with zero-time cycles. 
This leads to the following definition. 



Definition 3. A sequence of steps is tick-separated iff it contains no zero-time 
cycle, and for every time slice of the sequence one of the following two conditions 
holds: 



^ A more general definition would require that the process actions satisfy a confluence 
condition as far as the input and output actions are concerned, i.e., doing an input 
action does not invalidate the possibility of an output action, and vice versa. Also 
in this case, the process is not reactive, since there is no feed-back from input to 
output actions. 

^ A time slice of a run is a maximal subsequence of the run without tick-steps. 
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Table 4. Synchronous commnnication over rendezvons channel c 



'yi ^Ci?(s,v) ^1 0^2 ^Co!(s,^;) ^2 

(71,72) (71,72) 



COMMgy^ic 



1 . the time slice contains no output action; 

2 . the time slice contains no output over two different channels, and all locations 
in the time slice are input- discarding wrt. all inputs of that time slice. 

We call a process tick-separated if all its runs are tick-separated. 

Further we consider a synchronous version Pg and an asynchronous version 
Pa of a process P, where Pg is the process P together with a set of rendezvous 
channels, and Pa is formed by the process P together with a set of channels with 
the same names as for Pg but which are queues. Synchronous communication 
over a rendezvous channel c is defined by rule COMM^ync of Table 4. 

In the following, we call a configuration the combined state of a process 
together with the state of its channels. So given Pg and Pa and two correspond- 
ing states 7s = ag and 7a = {aa,{ci,q^),{cl,qi), . . . ,{c^,qk)), we define > as 
7a ^ 7s, if 0’s = CF a. Comparing the observable behavior of an asynchronous and 
a synchronous process, we must take into account that the asynchronous one 
performs more internal steps when exchanging messages with its queues. Hence 
the comparison is based on a weak notion of equivalence, ignoring the r-steps: 
so we define a weak step =7> as when Xffr, and as else. Corre- 

spondingly, =7y denotes a sequence of weak steps with labels from a sequence A. 

Lemma 4. Assume a synchronous and an asynchronous version Pg and Pa of 
a process P and corresponding states % and 7a with 7o ^ 7s, where the queues 
of 7a ore all empty. If 7a = 7 y ffa o tick- separated sequence, where A does not 
contain a tick-label, and where the queues of ffa ore empty, then there exists a 
sequence 7s 7' with ^ 7s. 

Proof. We are given a sequence 70 = 7 q 7i ■ • ■ ^a„_i In = 7a, "with the 
queues of 7g and 7“ empty. According to the definition of tzcfc-separation, we 
distinguish the following two cases: 

Case 1 : \ ^ {tick,c\{s,v)}, for all 1 < i < n — 1 

To get a matching reduction sequence of the synchronous system starting at 
7o, we apply the following renaming scheme. Input actions 7a ^c7(s,v) 7 a the 
queue are just omitted (which means, they are postponed for the synchronous 
process), r-steps 7a 7a, inputting a value from the queue into the process, 
i.e., r-steps justified by rule Comm where the process does a step a 
by rule Input and the queue the corresponding output step by rule Out, are 
replaced by a direct input steps 7^ ^c?(s,v) I'g- Process internal r-steps of the 
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asynchronous system are identically taken by the synchronous system, as well. 
T-steps caused by output actions from the process into a queue need not be dealt 
with, since the sequence from 7 q to 7“ does not contain external output from the 
queues, and the queues are empty at the beginning and the end of the sequence. 

It is straightforward to see that the sequence of steps obtained by this 
transformation is indeed a legal sequence of the synchronous system. More- 
over, the last configurations have the same state component and, due to the 
non-lossiness and the Fifo-behavior of the input queue, both sequences coincide 
modulo r-steps. 

Case 2 : no output over two different channels, input discarding locations (and 
no tick-steps) 

Similar to the previous case, the synchronous system can mimic the behavior 
of the asynchronous one adhering to the following scheme: r-steps 7^ 7^, 

feeding a value from the process into the queue, i.e., r-steps justified by rule 
Output where the process does a step a ^c\(s,v) and the queue the corre- 
sponding input step by rule In, are replaced by a direct output step 7^ ^c!(s,j;) 7 s- 
Input actions 70 ^c?(s,d) 7a into the queue are mimicked by a discard-step. Out- 
put steps from the queue of the asynchronous system are omitted, and so are 
r-steps caused by internal communication from the input-queue to the process. 
All other internal steps are identically taken in both systems. The rest of the 
argument is analogous to the previous case. □ 

Note that 7^ > 7^ means that 7^ is blocked whenever 7^ is blocked. 

We write \P\wtrace to denote the set of all weak traces of process P. To prove 
that for ticfc-separated processes \Ps\wtrace = \Pa\wtrace^ we introduce a notion 
of tzcfc-simulation that captures the ability to simulate any sequence of steps up 
to a tick step, i.e. the chosen granularity level are time slices and only the states 
immediately before and after tick are of importance there. (Remember that we 
assume the absence of zero-time cycles.) 

Definition 5. A binary relation TZ C Pi x P2 on two sets of states is called a 
t\c^^- simulation, when the following conditions hold: 

1 . // 71 7^72 and 71 ^uck 7u then 72 ^uck 72 7(7^72. 

2 . If 7 i 7^72 and 71 7) for some 7^ with blocked where A does not 

contain tick, then 72 72 for some 72 with blocked{'^2) and 7(7^72. 

We write 71 :<tick I2 if there exists a tick simulation TZ with 71 7^.72, and 
similarly for processes. Pi :<uck P2 if their initial states are in that relation. 

Theorem 6. If a process P is tick-separated, then \Ps\wtrace = \Pa\wtrace- 

Proof. There are two directions to show. iPsjwtrace Q \Pa\wtrace is immediate: 
each communication step of the synchronous process Pg can be mimicked by 
the buffered Pa with adding an internal T-step for the communication with the 
buffer. 
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For the reverse direction |-Palwtrace C \Ps\wtrace we show that Pa is simulated 
by Ps according to the definition of tzcfc-simulation, which considers as basic steps 
only tick-steps or else the sequence of steps within one time slice. 

We define the relation TZ C Pa x Pg as {aa,{{co,qo), ■ ■ ■ ,{cm,qm)))Pcrs iff 
o'a = 0’s and qi = e for all queues modelling the channels. To show that TZ is 
indeed a tzcfc-simulation, assume 70 = (cto, ((cq, e), . . . , (cm, e))) and 7^ = 0’s 
with jaTZls- There are two cases to consider. 

Case: 7a ^ttck 7a 

where 7a = 7a[* By the definition of the tzcfc-step, blockedi^a) must hold, 

i.e., there are no steps enabled except input from the outside or tzcfc-steps. Since 
immediately blocked{js), also 7^ -^uck 7s[*'-^(t-i)]) which concludes the case. 

Case: -fa 7a 

where blocked{j'^) and A does not contain a tzcfc-label. The case follows directly 
from Lemma 4 and the fact that 7^ > 7' where 7^ is blocked implies that also 
7' is blocked. 

Since clearly the initial states are in relation TZ as defined above, this gives 
Pa ditick Ps- Since Pa f^tick Ps and each tick-step of Pa can be mimicked by the 
tick step of Pg and each weak step of Pa can also be mimicked by Pg. That 
implies |F^a|^i;trace C J lyirace ? as required. D 

4 Abstracting Data 

Originating from an unknown or underspecified environment, signals from out- 
side can carry any value, which renders the system infinite state. Assuming 
nothing about the data means one can conceptually abstract values from out- 
side into one abstract “chaotic” value, which basically means to ignore these 
data and focus on the control structure. Data not coming from outside is left 
untouched, though chaotic data from the environment influence internal data 
of the system. In this section, we present a straightforward dataflow analysis 
marking variable and timer instances that may be influenced by the environ- 
ment, namely we establish for each process- and timer-variable in each location 
whether 

1. the variable is guaranteed to be non-chaotic, or 

2. the variable is guaranteed to be influenced by the outside, or 

3. whether its status depends on the actual run. 

The analysis is a combination of the ones from [29] and [17]. 

4.1 Dataflo-w Analysis 

The analysis works on a simple flow graph representation of the system, where 
each process is represented by a single flow graph, whose nodes n G nodes are 
associated with the process’ actions and the flow relation captures the intra- 
process data dependencies. Since the structure of the language we consider is 
rather simple, the flow-graph can be easily obtained by standard techniques. 




Synchronous Closing and Flow Analysis 303 



We use an abstract representation of the data values, where T is interpreted 
as value chaotically influenced by the environment and _L stands for a non-chaotic 
value. We write 77“, . . . for abstract valuations, i.e., for typical elements from 

VoZ“ = Var {T, _L}. The abstract values are ordered _L < T, and the order is 
lifted pointwise to valuations. With this ordering, the set of valuations forms a 
complete lattice, where we write ?7 _l for the least element, given as rj^{x) = _L for 
all X G Vor, and we denote the least upper bound of 77“, . . . , 77“ by Vr=i V? (or 
by rii V 772 in the binary case). By slight abuse of notation, we will use the same 
symbol 77“ for the valuation per node, i.e., for functions of type node Val°" . 
The abstract valuation |e],,c« for an expression e equals T iff all variables in e 
are evaluated to T, \e\^a is T iff the abstract valuation of at least one of the 
variables in e is T. 

Depending on whether we are interested in an answer to point ( 1 ) or point ( 2 ) 
from above, T is interpreted as a variable potentially influenced from outside, 
and, dually for the second case, T stands for variables guaranteed to be influenced 
from outside. Here we present may and must analysis for the first and the second 
case respectively. 

May Analysis. First we consider may analysis that marks variables potentially 
influenced by data from outside. Each node n of the flow graph has associated 
an abstract transfer function /„ : Val°‘ Val°‘ , describing the change of the 
abstract valuations depending on the kind of action at the node. The functions 
are given in Table 5 . The equations are mostly straightforward; the only case de- 
serving mention is the one for cls{x), whose equation captures the inter-process 
data-flow from a sending to a receiving action. It is easy to see that the transfer 
functions are monotone. 

Upon start of the analysis, at each node the variables’ values are assumed to 
be defined, i.e., the initial valuation is the least one: = ’tx- This choice 

rests on the assumption that all local variables of each process are properly 
initialized. We are interested in the least solution to the data-flow problem given 
by the following constraint set: 

Vpostin) > fniVprein)) 

Vprein) > \/{Vpost{n') I (n',n) in flow relation} ^ ^ 



Table 5 . May analysis: transfer functions/abstract effect for process P 



f{c 7 s{x))y°‘ 






f{g>ds{e))y°‘ = ri°‘ 
f(g>x := e)y°‘ = [x 
f{g> set t := e)y°‘ = <,n([e],a)] 

f{g\> reset t)rj°‘ =ri°‘[t^off] 
f{gt > reset t)ri°‘ = 



\n'^g t> c!s(e)}] 



« ^ SiQext 
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For each node n of the flow graph, the data-flow problem is specified by two 
inequations or constraints. The first one relates the abstract valuation 77 “^^ before 
entering the node with the valuation 77 “^^^ afterwards via the abstract effects of 
Table 5. The least flxpoint of the constraint set can be found iteratively in a fairly 
standard way by a worklist algorithm (see e.g., [19,14,24]), where the worklist 
steers the iterative loop until the least flxpoint is reached (cf. Figure 1). 



input : the flow— graph of the program 

output . gpre^ Vpost i 

V°‘{n) = vTuitin ) ; 

WL^{n\ a„ =?s{x), s € Sig^^} ; 

repeat 

pick n G WL ; 

if n — gt>c\s{e) then 





let 


S' = 


= {n' 1 n' 


= c?s(x) and |e]^c 


(n) ^ 11^1 r?' 




in 














for 


all n' GS'-. 77“(n'):=/n 


,(77“(n')); 


let 


S = 


{n" G 


succ(n) 1 


/4^“(n)) ^ r;“(n' 


')} 


in 














for 


all 


n" GS-. 


^“(n") :=/„(r,“(n)); 


WL : 


1 

II 


u S'u S' 


1 





unt il WL — 0 ; 

Vprein) = V°‘{n) ; 

Vpost{n) = 



Fig. 1. May analysis: worklist algorithm 

The worklist data-structure WL used in the algorithm is a set of elements, 
more specifically a set of nodes from the flow-graph, where we denote by succ(n) 
the set of successor nodes of n in the flow graph in forward direction. It supports 
as operation to randomly pick one element from the set (without removing it), 
and we write WL\{n\ for the worklist without the node n and U for set-union on 
the elements of the worklist. The algorithm starts with the least valuation on all 
nodes and an initial worklist containing nodes with input from the environment. 
It enlarges the valuation within the given lattice step by step until it stabilizes, 
i.e., until the worklist is empty. If adding the abstract effect of one node to the 
current state enlarges the valuation, i.e., the set S is non-empty, those successor 
nodes from S are (re-)entered into the list of unfinished one. Since the set of 
variables in the system is finite, and thus the lattice of abstract valuations, the 
termination of the algorithm is immediate. 

With the worklist as a set-like data structure, the algorithm is free to work off 
the list in any order. In praxis, more deterministic data-structures and traversal 
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strategies are appropriate, for instance traversing the graph in a breadth- first 
manner (see [24] for a broader discussion or various traversal strategies). 

After termination the algorithm yields two mappings ?7pre>’7post • ^ode 
Val°‘ . On a location I, the result of the analysis is given by = V{^post(^) I 
h = I — >a 1}, also written as rjf. 

Lemma 7 (Correctness (may)). Upon termination, the algorithm gives back 
the least solution to the constraint set as given by the equations (1), resp. Table 5. 

Must Analysis. The must analysis is almost dual to may analysis. A transfer 
function that describes the change of the abstract valuation depending on the 
action at the node is defined in Table 6. For inputs, c?s(x) in process P assigns 
T to a: if the signal is sent to P with reliable data, only. This means the values 
after reception correspond to the greatest lower bound over all expressions which 
can occur in a matching send-action. 



Table 6. Must analysis: transfer functions/abstract effect for process P 



f{c?s{x))g°‘ 






f(g>c\s{e))g°‘ = p°‘ 
fig^x := e)g°‘ = 

f{g\> set t := e)g°‘ = on(ie}^c)] 

f{g> reset t)g°‘ 
f{gt > reset t)g°‘ = 



n'=g t> c!s(e)}] 



S ^ Sigint 
S e Sigint 



As that is done for may analysis, the data-flow problem is specified for each 
node n of the flow graph by two inequations (2) (see Table 6). Analogously, 
the greatest fixpoint of the constraint set can be found iteratively by a worklist 
algorithm (cf. Figure 2). Upon start of the analysis, at each node the variables’ 
values are assumed to be defined, i.e., the initial valuation is the greatest one: 
'nfmtin) = VT- 



Vpostin) < fniVprein)) 

A (2) 

Vprein) < /\{Vpost(n') I (n',n) in flow relation} 

Like the may-analysis case, the termination of the algorithm follows from the 
finiteness of the set of variables. 

Lemma 8 (Correctness {must)). Upon termination, the algorithm from Fig- 
ure 2 gives back the greatest solution to the constraint set as given by equa- 
tions (2) resp. Table 6. 
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input : the flow— graph of the program 

output . ^pre^ Vpost i 

V°‘{n) = vTmtin ) ; 

WL = {n\ a„ = g\> X := e\ \ 

repeat 

pick n G WL ; 

if n = g\>c\s{e) then 

let S' = {n' I n' = cls{x) and ^ |a;],,c.(„/)} 

in 

for all n' G S' : g°‘{n') := ■, 

let S = {n" G succ{n) \ fn{g°‘{n)) ^ 

in 

for all n" G S : := fn{g°‘{n)) ■, 

WL ■- WL\{n} USDS'-, 
unt il WL — 0 ; 



Vpre{n) = g°‘{n ) ; 
Vpostin) = fn{v°‘{n)) 



Fig. 2. Must analysis: worklist algorithm 



4.2 Program Transformation 

Based on the result of the analysis, we transform the given system S = P \\ P 
into an optimized one, denoted by S^, where the communication of P with its 
environment P is done synchronously, all the data exchanged is abstracted, and 
which is in a simulation relation with the original system. 

The intention is to use the information collected in the analyses about the 
influence of the environment to reduce the state space. Depending on whether one 
relies on the may-analysis alone (which variable occurrences may be influenced 
from the outside) or takes into account the results of both analyses (additional 
information which variable occurrences are definitely chaotic) the precision of 
the abstraction varies. Using only the may-information overapproximates the 
system (further) but in general leads to a smaller state space. 

The second option, on the other hand, gives a more precise abstraction and 
thus less false negatives. Indeed, it does not, apart from the abstraction caused 
by introducing chaotic values, abstract the system further as far as the behavior 
is concerned. It is nevertheless profitable as it allows to remove any unnecessary 
instances of variables or expressions which are detected to be T constantly. It 
furthermore can make further optimizations of the system more effective. For 
instance, live analysis and the optimization as described in [4] can be effective 
for more variable instances and thus yield better further reduction when applied 
after replacing variable instances which are constantly T. 
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In either case we must ensure that the abstraction of timer values is treated 
adequately (see below) . Here we describe the transformation for the combination 
of may and must analysis, only, since the alternative is simpler. 

Overloading the symbols T and _L we mean for the rest of the paper: the value 
of T for a variable at a location refers to the result of the must analysis, i.e., the 
definite knowledge that the data is chaotic for all runs. Dually, _L stands for the 
definite knowledge of the may analysis, i.e., for data which is never influenced 
from outside. Additionally, we write I in case neither analysis gave a definite 
answer. 

We extend the data domains each by an additional value T, representing 
unknown, chaotic, data, i.e., we assume now domains such as = N U {T}, 
Boof^ = Bool U {T}, . . . , where we do not distinguish notationally the various 
types of chaotic values. These values T are considered as the largest values, i.e., 
we introduce < as the smallest reflexive relation with w < T for all elements v 
(separately for each domain). The strict lifting of a valuation 77^ to expressions 
is denoted by |.],;T. 

The transformation is straightforward: guards influenced by the environment 
are taken non-deterministically, i.e., a guard <7 at a location I is replaced by true, 
if = T. A guard g whose value at a location Hs I is treated dynamically on 
the extended data domain. For assignments, we distinguish between the variables 
that carry the value I in at least one location and the rest. Assignments of T to 
variables that take I at no location are omitted. Assignments of concrete values 
are left untouched and the assignments to the variables that are marked by I 
in at least one location are performed on the extended data domain. 

The interpretation of timer variables on the extended domain requires spe- 
cial attention. Chaos can influence timers only via the set-operation by setting 



Table 7. Transformation 



1 — ^c?s(_) i ^ Edg^ 


- - '1 


^ > c!(s,e) ^ ^ Edg 


T-Output 


1 ^g«t>c!(s,T) 1 ^ Edg^ 




1 — >g > a;:=e 1 £ Edg X ^ Varx 


IxU = T 


1 — ^ 9 # > skip 1 ^ Edg'^ 

1 — >9 > a;:=e 1 £ Edg X £ Vavx 


[el.f = T , 



^ > x: = T I ^ 

I > set t~e 1 £ Edg |e]r 7 p ~ m o 

; ^ T-Set 

I > set t: = T ^ ^ Edg 



T-AsSIGNi 

T-ASSIGN2 
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it to a chaotic value. Therefore, the domain of timer values contains the addi- 
tional chaotic value on(T). Since we need the transformed system to show at 
least the behavior of the original one, we must provide proper treatment of the 
rules involving on(T), i.e., the Timeout-, the TDiscard-, and the TiCK-rule. 
As on(T) stands for any value of active timers, it must cover the cases where 
timeouts and timer-discards are enabled (because of the concrete value on(0)) 
as well as disabled (because of on{n) with n > 1). The second one is necessary, 
since the enabledness of the tick steps depends on the disabledness of timeouts 
and timer discards via the blocked-condition. 

To distinguish the two cases, we introduce a refined abstract value on(T+) 
for chaotic timers, representing all on-settings larger than or equal to 1. The 
order on the domain of timer values is given as smallest reflexive order relation 
such that on(0) < on(T) and on{n) < on(T+) < on(T), for all n > 1. To treat 
the case where the abstract timer value on(T) denotes absence of immediate 
timeout, we add edges of the form 



T-NoTimeout 

I *t^on(T) t> set t--T+ I ^ dSdg 

which set back the timer value to T"*" representing a non-zero delay. 

The decreasing operation needed in the TiCK-rule is defined in extension to 
the definition on values from on(N) on T+ by on(T+) — 1 = on(T). Note that 
the operation is left undefined on T, which is justified by a property analogous 
to Lemma 1: 

Lemma 9. Let be a state of SK If ^uck , then |t],,T ^ 

{on(T), on(0)}, for all timers t. 

Proof. By definition of the blocked-predicate and inspection of the Timeout- 
and TDiSCARD-rule (for on(0) as for Lemma 1) and the behavior of the abstract 
value on(T) (T-NoTiMEOUT-rule). □ 

As the transformation only adds non-determinism, the transformed system S'** 
simulates S (cf. [29]). Together with Theorem 6, this guarantees preservation of 
LTL-properties as long as variables influenced by P are not mentioned. Since we 
abstracted external data into a single value, not being able to specify properties 
depending on externally influenced data is not much of an additional loss of 
precision. 

Theorem 10. Let Sa and Sg be the variant of a system communicating to the 
environment asynchronously resp. synchronously, and S be given as the parallel 
composition Sa || S, where S is the environment of the system. Furthermore, let 
S® = S| II S be defined as before, and ip a next-free LTL-formula mentioning 
only variables from {x | V/ G Loc. = T}. Then S'^ \= implies S \= <p. 
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5 Example: A Wireless ATM Medium- Access Protocol 

The goal of our experiments is to estimate the state space reduction due to re- 
placing asynchronous communication with the environment by the synchronous 
one. Primarily interested in the effect of removing queues, we use here the most 
trivial environment: the chaotic one. 

We applied the methods in a series of experiments to the industrial protocol 
Mascara [33]. Located between the ATM-layer and the physical medium, Mas- 
cara is a medium-access layer or, in the context of the ISDN reference model, 
a transmission convergence sub-layer for wireless ATM communication in local 
area networks. A crucial feature of Mascara is the support of mohility. A mobile 
terminal (MT) located inside the area cell of an access point (AP) is capable 
of communicating with it. When a mobile terminal moves outside the current 
cell, it has to perform a so-called handover to another access point covering the 
cell the terminal has moved into. The handover must be managed transparently 
with respect to the ATM layer, maintaining the agreed quality of service for the 
current connections. So the protocol has to detect the need for a handover, select 
a candidate AP to switch to, and redirect the traffic with minimal interruption. 

This protocol was the main case study in the Vires project; the results of its 
verification can be found e.g. in [3, 13,30]. The SDL-specification of the proto- 
col was automatically translated into the input language of DTSpin [2,11], a 
discrete-time extension of the well-known Spin model-checker [16]. For the trans- 
lation, we used SDl2if [5] and ip2PML-translators [3]. Our prototype implemen- 
tation, the PML2PML-translator, post-processes the output from the automatic 
translation of the SDL-specification into DTPromela. 

Here, we are not interested in Mascara itself and the verification of its prop- 
erties, but as real-life example for the comparison of the state spaces of parts 
of the protocol when closed with the environment as an asynchronous chaotic 
process and the state space of the same entity closed with embedded chaos. For 
the comparison we chose a model of the Mascara control entity (MCL) at the 
mobile terminal side In our experiments we used DTSpin version 0.1.1, an ex- 
tension of Spin3.3.10, with the partial-order reduction and compression options 
on. All the experiments were run on a Silicon Graphics Origin 2000 server on a 
single R10000/250MHz CPU with 8GB of main memory. 

The implementation currently covers the may analysis and the corresponding 
transformation. We do not model the chaotic environment as a separate process 
communicating with the system via rendezvous channels but transform an open 
DTPromela model into a closed one by embedding the timed chaotic environ- 
ment into the system as described in [29], which allows us to use the process 
fairness mechanism provided by Spin, which works only for systems with asyn- 
chronous communication. The translator does not require any user interaction, 
except that the user is requested to give the list of external signals. The exten- 
sion is implemented in Java and requires JDK-1.2 or later. The package can be 
downloaded from http://www.cwi.nl/~ustin/EH.html. 
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Table 8. Model checking MCL with chaos as a process and embedded chaos 



bs 


states 


transitions 


mem. 


time 


states 


transitions 


mem. 


time 


2 


9.73e-t05 


3.64e-t06 


40.842 


15:57 


300062 


1.06e+06 


9.071 


1:13 


3 


5.24e-t06 


2.02e-t07 


398.933 


22:28 


396333 


1.85e+06 


11.939 


1:37 


4 


2.69e-t07 


1.05e-t08 


944.440 


1:59:40 


467555 


2.30e+06 


14.499 


2:13 



Table 8 gives the results for the model checking of MCL with chaos as external 
process on the left and embedded on the right. The first column gives the buffer 
size for process queues. The other columns give the number of states, transitions, 
memory and time consumption, respectively. As one can see, the state space 
as well as the time and the memory consumption are significantly larger for 
the model with the environment as a process, and they grow with the buffer 
size much faster than for the model with embedded chaos. The model with the 
embedded environment has a relatively stable state-space size. 

6 Conclusion 

In this paper, we integrated earlier works from [29, 18, 31, 17] into a general 
framework describing how to close an open, asynchronous system by a timed 
environment while avoiding the combinatorial state-explosion in the external 
buffers. The generalization presented here goes a step beyond complete arbitrary 
environmental behavior, using the timed semantics of the language. We facilitate 
the model checking of the system by using the information obtained with may 
and must analyses: We substitute the chaotic value T for expressions influenced 
by chaotic data from outside and then optimize the system by removing variables 
and actions that became redundant. 

In the context of software-testing, [9] describes an a dataflow algorithm to 
close program fragments given in the C-language with the most general envi- 
ronment. The algorithm is incorporated into the VeriSoft tool. As in our paper, 
the assume an asynchronous communicating model and abstract away external 
data, but do not consider timed systems and their abstraction. As for model- 
checking and analyzing SDL-programs, much work has been done, for instance 
in the context of the Vires-project, leading to the IF-toolset [5] 

A fundamental approach to model checking open systems is known as module 
checking [21] [20]. Instead of transforming the system into a closed one, the un- 
derlying computational model is generalized to distinguish between transitions 
under control of the module and those driven by the environment. Mocha [1] 
is a model checker for reactive modules, which uses alternating-time temporal 
logic as specification language. 

For practical applications, we are currently extending the larger case study 
[30] using the chaotic closure to this more general setting. We proceed in the fol- 
lowing way: after splitting an SDL system into subsystems following the system 
structure, properties of the subsystems are verified being closed with an embed- 
ded chaotic environment. Afterwards, the verified properties are encoded into 
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an SDL process, for which a tick-separated closure is constructed. This closure 
is used as environment for other parts of the system. As the closure gives a safe 
abstraction of the desired environment behavior, the verification results can be 
transferred to the original system. 
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Abstract. We present a framework for the incremental construction 
of deadlock-free systems meeting given safety properties. The frame- 
work borrows concepts and basic results from the controller synthesis 
paradigm by considering a step in the construction process as a con- 
troller synthesis problem. 

We show that priorities are expressive enough to represent restric- 
tions induced by deadlock-free controllers preserving safety properties. 
We define a correspondence between such restrictions and priorities and 
provide compositionality results about the preservation of this corre- 
spondence by operations on safety properties and priorities. Finally, we 
provide an example illustrating an application of the results. 



1 Introduction 

A common idea for avoiding a posteriori verification and testing, is to use system 
design techniques that guarantee correctness by construction. Such techniques 
should allow to construct progressively from a given system S and a set of re- 
quirements Ri, , Rn, a sequence of systems Si, . . . , Sn, such that system Si 
meets all the requirements Rj for j < i. That is, to allow incremental construc- 
tion, requirements should be composable [2,6] along the design process. In spite 
of their increasing importance, there is currently a tremendous lack of theory 
and methods, especially for requirements including progress properties which 
are essential for reactive systems. Most of the existing methodologies deal with 
construction of systems such that a set of state properties always hold. They are 
founded on the combined use of invariants and refinement relations. Gompos- 
ability is ensured by the fact that refinement relations preserve trace inclusion. 
We present a framework allowing to consider jointly state property invariance 
and deadlock- freedom. 

Practice for building correct systems is often based on the idea of adding 
enforcement mechanisms to a given system S in order to obtain a system S' 
meeting a given requirement. These mechanisms can be implemented by instru- 
menting the code of S or by composing S with systems such as controllers or 
monitors that modify adequately the overall behavior. 

An application of this principle is the enforcement of security policies which 
are safety properties described by automata [14]. A main requirement for the 
enforced system is that it safely terminates when it detects a deviation from 
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some nominal secure behavior. A more difficult problem is also to ensure system 
availability and preserve continuity of service [3,10]. 

Another application of this principle is aspect oriented programming [8] used 
to build programs meeting (usually simple) requirements. Aspects can be con- 
sidered as requirements from which code is generated and woven into a program 
intended to meet the requirements. In aspect oriented programming, aspect com- 
position is identified as a central problem as it may cause unintentional interfer- 
ence and inconsistency [15]. 

Practice for building correct systems by using enforcement mechanisms raises 
some hard theoretical problems. For a sufficiently fine granularity of observation, 
it is relatively easy to enforce safety requirements (as non violations of given state 
properties) by stopping system progress. It is much harder to devise mechanisms 
that also guarantee system availability and avoid service interruption. Further- 
more, composability of requirements e.g. security policies, aspects, is identified 
as a main obstacle to rigorous incremental system construction. 

We propose a design framework for both safety and deadlock-freedom re- 
quirements. The framework consists of a model, priority systems and results 
concerning its basic properties including composability. A priority system is a 
transition system with a (dynamic) priority relation on its actions. A priority re- 
lation ^ is a set of predicates of the form ^ Cij-Oj meaning that action ai has 
lower priority than action aj at all states satisfying Cij. At a given state of the 
transition system, only enabled actions with maximal priority can be executed. 
That is, in a priority system, a priority relation restricts the behavior of its tran- 
sition system exactly as a scheduler restricts the behavior of a set of tasks. The 
remarkably nice property of priority systems is that they are deadlock-free if 
they are built from deadlock-free transition systems and from priority relations 
satisfying some easy-to-check consistency condition. 

The proposed framework considers design as a controller synthesis [12] prob- 
lem: from a given system S and requirement R, find a system S' meeting R. 
S' is the composition of S with a controller which monitors the state of S and 
restricts its behavior by adequately switching off a subset of controllable actions 
of S. The controller is usually specified as a solution of a fixpoint equation. 

The simple case where R means that S' is deadlock-free and does not violate 
a state predicate U has been studied in various contexts e.g., in [11,1]. The 
corresponding controller is specified as a deadlock-free control invariant which is 
a state predicate U', U' ^ U, such that 

~ it is preserved by the non controllable actions of S, that is if U' holds at 

some state then it remains true forever if only non controllable actions are 

executed; 

— U' is false for all deadlock states of S. 

Given U' , the controlled (designed) system S' is obtained from S by con- 
juncting the guard of any controllable action a by the weakest precondition of 
U' under a. 

In Section 2, we formalize the relationship between S and S', by introducing 
restriction operators. These are specified as tuples of state predicates in bijection 
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with the set of actions of S. The application of a restriction operator to S is S', 
obtained from S by conjuncting the guards of its actions by the corresponding 
state predicates of the restriction. We study properties of deadlock-free control 
restrictions, that is restrictions corresponding to deadlock-free control invariants. 

In Section 3, we show that under some consistency conditions, priorities 
can be used to represent deadlock-free restrictions. Thus, controlled systems 
S' can be represented as deadlock-free priority systems. Consistency checking 
boils down to computing a kind of transitive closure of the priority relation. We 
show that for static priorities consistency is equivalent to deadlock-freedom. 

Composability in our framework means commutativity of application of pri- 
orities on a given system. As a rule, the result of the successive restriction of 
a system S by two priorities and ^2 depends on the order of application 
and we provide sufficient conditions for commutativity. This difficulty can be 
overcome by using a symmetric composition operator 0 for priorities which pre- 
serves safety and deadlock-freedom. The restriction of a system S' by 0 02 
is a refinement of any other restriction of S obtained by application of and 
~< 2 - 

An interesting question is whether priorities are expressive enough to repre- 
sent restrictions induced by deadlock-free control invariants. We bring a positive 
answer by using a construction associating with a state predicate U a priority 
relation We show that if {7 is a deadlock- free control invariant then the 
controlled system S' is equivalent to the system S restricted by 0[/. Further- 
more, we provide results relating the controlled systems corresponding to U\, 
C/ 2 , Ui A C /2 to restrictions by ^0 ® ®c/ 2 - 

Section 4 illustrates application of the results on an example. 

Section 5 presents concluding remarks about the presented framework. 



2 Deadlock-Free Control Invariants 

2.1 Definitions and Basic Properties 

Definition 1 (Transition System). A transition system B is a tuple (X,A, 
{G“}aeA,{A“}aeA), where 

— X is a finite set of variables; 

— A is a finite set of actions, union of two disjoint sets A“ and A" , the sets of 
the uncontrollable and controllable interactions respectively; 

~ G°" is a guard, predicate on X; 

— \ X X is a transition function, where X is the set of valuations of X. 



Definition 2 (Semantics of a Transition System). A transition system {X, 
A{GnaeA,{A“}aeA) defines a transition relation — X x A x X such that: 
Vx,x' G X Va G A . X A x' ^ G“(x) A x' = A“(x). 
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We introduce the following notations: 

— Given two transition systems Bi, B 2 with disjoint action vocabularies such 

that B, = for i = 1,2, their union is the 

transition system B 1 UB 2 = (X 1 UX 2 , AiU^ 2 , {G“}aeAiUA 2 , {-P^^jaeAiuAs)- 

— Given a transition system B, we represent by i?“ (respectively i?°) the tran- 
sition system consisting of the uncontrollable (respectively controllable) ac- 
tions of B. Glearly B = U B’^. 

— Given a transition system B, we represent by G{B) the disjunction of its 
guards, that is G{B) — VaeA where A is the set of the actions of B. 

Definitions (Predecessors). Given B = (X, A, {G“}aeA, {^“Ioga) and a 
predicate U on X, the predecessors ofU by action a is the predicate prea{U) = 
G“ A U{[F‘^{X)/X]) where U[F°-{X)/X] is obtained from U by uniform substi- 
tution of X by F°‘{X). 

Glearly, prCa{U) characterizes all the states from which execution of a leads 
to some state satisfying U. 

Definition 4 (Invariants and Control Invariants). Given a transition sys- 
tem B and a predicate U, 

— U is an invariant of B if U /\a(=A^P^^a{^U) = AaeA(^^'* 

U{[F°-{X)/X]). An invariant U, U ^ false, is called deadlock-free if U ^ 
G{B). 

— U is a control invariant of B ifU ^ f\aGA^ ~^prea{~^U). A control invariant 
U , U false, is called deadlock-free ifU^ VaeAP''’®o(^)- 

We write inv[B]{U) to express the fact that U is an invariant of B. Notice 
that invariants are control invariants of systems that have only uncontrollable 
actions. 

Proposition 1. IfU is a control invariant of B = (X, A, {G“}aeA, {.F“}aeA) 
then U is an invariant of B' = {X, A, {{G°'y}aeA, {F°’}aeA) where (G“)' = 
G°“ f\U[F°-{X) / X] fora G A‘^ and (G“)' = G“ otherwise. Furthermore, ifU is a 
deadlock-free control invariant of B then it is a deadlock-free invariant of B' . 

This result allows to build from a given system B and a safety requirement 
of the form ’’always C/q” a deadlock- free system B' meeting this requirement, 
provided there exists a deadlock- free control invariant U oi B such that U ^ Uq- 
The following simple example illustrates this fact. 

Example 1. In a Readers/ Writers system, we use two counters, non negative 
integers, r and w to represent respectively, the number of readers and writers 
using a common resource. The counters are modified by actions of a transition 
system B specified as a set of guarded commands: 

oi : true ^ r := r + 1 02 ■ r > 0 ^ r := r — 1 

bi : true ^ w := w + 1 b 2 '■ w > 0 ^ w := w — 1 
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where a\ and bi are respectively, the actions of granting the resource to a reader 
and a writer and 02 and &2 £^re respectively, the actions of releasing the resource 
by a reader and a writer. 

We assume that the actions a\ and 61 are controllable and we want to enforce 
the requirement ’’always U” for [/ = (ru < 1) A (w = 0 V r = 0). This prevents 
concurrent access among writers, as well as between readers and writers. It is 
easy to check that C/ is a deadlock-free control invariant. In fact, it is easy to 
check that U is preserved by the uncontrollable actions 02 and 62 : 

(r > 0) A [/ =k U[r — 1/r] and (w > Q) f\U =k U[w — l/w\. 

Furthermore, it is easy to check that U =k V prCaa V . 

As prCaiiU) = w = 0 and preb^{U) = {w = 0 ) A {r = 0), we have inv[B']{U) 
where B' is the controlled transition system: 

ai:'u; = 0^r:=r-|-l O2:r>0^r:=r— 1 

61 : (r = 0) A (w = 0) ^ w := w -I- 1 b2 '■ w > 0 ^ w := w — 1 

The notion of restriction defined below allows a formalization of the relation- 
ship between the initial and the controlled system. 

Definition 5 (Restriction). Given a transition system B = {X, A, {G‘^}a^A, 
{F-} aeA), 0, restriction is a tuple of predicates V = (U°')aeA- B/V denotes the 
transition system B restricted by V, B/V = (A, A, {G“ A U°'}a^A, 

V = {U°‘)a^A is a control restriction for B t/ = true. 

V = lu°')aeA is a deadlock-free restriction for B if\Jg^^^ G“A[/“ = VaeA 

We simply say that V is a control restriction or a deadlock-free restriction if 
the corresponding equation holds for any transition system B with vocabulary of 
actions A = A‘^\J A“ (independently of the interpretation of the guards). 

Definition 6 V{U)). Given a predicate U, we denote by the restric- 

tion = {U)aeA, and by V{U) the restriction V(U) = {U[F°‘{X)/X])aeA- 
U ^1; V2 are two restrictions, Vj = {U°/')ai^A for j = 1, 2, we write V\ A V2 
for the restriction (C/“* A C/2*)aiGA- 

Proposition 2 (Control Invariants and Restrictions). Given a transition 
system B and a predicate U, 

a) If U is a control invariant of B then V{U) is a control restriction of B; 

b) IfU is a deadlock-free invariant of B then V(JJ) is a deadlock-free restriction 
ofB; 

c) IfU is a deadlock-free control invariant of B then V{U) is a deadlock-free 

control restriction of B. 

We need the following definitions for the comparison of transition systems. 

Definition 7 (Refinement and Equivalence). Given Bi = {Xi,A, {G“}ogA; 
{Ff} aeA) for i = 1 , 2 , two transition systems and a predicate U we say that 
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— Bi refines B2 under U, denoted by Bi Qu B2, ifVaGA. Fi = F2 and 
U AG<l^UA G^; 

— Bi is equivalent to B2 under U , denoted by B\ :^u B2, if B\ Cj/ B2 and 
B2 Qu Bi. 

We write B\ C B2 and B\ ~ B2 for B\ B2 and B\ ~true B2, respec- 

tively. 

Property 1 . Given transition systems B, Bi, B2 and restrictions V, Vi, V2, 
la B/V E B; 

lb {Bi U B2)/V ~ Bi/V U B2/V; 

Ic {BlV^)jV2 ~ B/{Vi A V2); 

Id -Bi E -82 {inv[B2]{U) inv[Bi]{U)) for any predicate U. 

Notice that if the conjunction of control invariants is a control invariant, the 
conjunction of deadlock-free control invariants is not in general, a deadlock-free 
control invariant. We investigate conditions for composability. 



3 Priority Systems 

We define priority systems which are transition systems restricted with priorities. 
Priorities provide a general mechanism for generating deadlock- free restrictions. 

3.1 Deadlock-Free Restrictions and Priorities 
Priorities 

Definition 8 (Priority). A priority on a transition system B with set of ac- 
tions A is a set of predicates {Cij}ai a^eA- The restriction defined by A, 
V{B,^) = {U-Ua ts A G“0- 

The predicates Cij specify priority between actions Ui and aj. If Cij is true 
at some state, then in the system restricted by V{B,~<) the action Ui cannot 
be executed if aj is enabled. We write Oi -< Cij.aj to express the fact that Oi is 
dominated by Oj when G^ holds. A priority is irreflexive if G^ for all 

ai,Qj G A. 

Definition 9 (Transitive Closure). Given a priority -< we denote by the 
least priority such that , obtained by the rule: 

Oi Gij.Oj and aj Gjk-ak implies Oi {Gjk A Gjk).ak- 

Proposition 3 (Activity Preservation for Priorities). A priority -< defines 
a deadlock-free restriction if is irreflexive. 

Proof. Suppose that is irreflexive. Consider some transition system B = 
{X, A, {G“}ae. 4 , {B“}ae. 4 ), and let G = VaeA and V(B, ^) = (C/“)ae^. Let 
X be a state of B such that G(x), let A' = {a & A \ G“(x)}, and define a relation 
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on A' such that yai,aj G A' . ai aj Cij(x). As is irreflexive, 

is a partial order on A', and thus acyclic. If A' 7^ 0 then max A' exists and is 
non-empty. Thus, ( G“ A C/“) (x) = (VaeA'G“)(x) = (Va6AG“)(x). ■ 

The above proposition motivates the definition of priority systems which are 
transition systems restricted by priorities. 

Definition 10 (Priority System). A priority system is a pair (B,^) where 
B is a transition system and -<= {Gy}oi,o„GA is a priority on B such that 
Cij = false for all (ai,aj) G A“ x A. 

The priority system (B,^) represents the transition system B/V{B,^). 

The following propositions give properties of priority systems. 

Proposition 4. If (B,^) is a priority system, then V{B,^) is a control re- 
striction for B . 

Proof. If V{B, then for all uncontrollable actions Oj, [/“• = true 

because Cij = false. ■ 

Corollary 1. If U is a control invariant of B then U is a control invariant of 

Proposition 5. If U is a deadlock-free control invariant of a transition sys- 
tem B then for any priority -< such that is irreflexive, U is a deadlock-free 
invariant of {B /V{U),^). 

Proof. If 17 is a deadlock- free control invariant of B then U =k G{B /V{U)) and 
inv[B'^]{U). As A defines deadlock-free restrictions, {B/V{U),-<Y = 
G{B/V{U)) = G{B/V{U),<) . ■ 

Static Priorities 

Definition 11 (Static Priority). A si&iic priority is a priority <={Cij}ai,aj£ A 
such that the predicates Cij are positive boolean expressions on guards. We call 
static restrictions the corresponding restrictions V{B,W) = {U°')a^A, that is 
restrictions which are tuples of negative boolean expressions on guards. 

It is easy to check that any static restriction defines a static priority. Notice 
that in a priority system with static priorities, the choice of the action to be 
executed at some state depends only on the set of the actions enabled at this 
state. For example, a restriction with 17“^ = A {^G°‘^ y ^G°“^) means that in 
the restricted system the action oi can be executed only if 02 is disabled and 03 
or 04 is disabled. The corresponding the priority relation is: oi A trwe. 02,01 A 
G“A04,0i a G“A03 

Notation: For a static priorities the notation can be drastically simplified. 

If {U°'')ai^A is a static restriction then it is of the form, [/“• = Afceic 
where is a monomial on guards Mf = Each monomial , 
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corresponds to the set of priorities {oj .aj}j^w- This set can 

be canonically represented by simply writing ai -< 

For example if Mf = G°-^ A A G°-^ instead of writing a^ A (G“^ A G“^).03, 
ai A (G“i A G“3).a2, Oj A (G“=^ A G“3).a;^, we write a* A 010203. We propose the 
following definition for static priorities. 

Definition 12 (Static Priority Simplified Definition). A monomial m 
on a vocabulary of actions A is any term m = aj^ . . . Oj„ obtained by using 
an associative, commutative and idempotent product operation. Let 1 denote its 
neutral element, and m(^) the set of the monomials on A. 

A static priority ^ on A is a relation yl x m(A). 

Example 2 . The static priority A corresponding to the static restriction = 
true, = true, = ^G“iV^G“=, = ^G“i A^G“A = ^G“iA^G“W 

^G “2 A ^G“‘‘ = ^(G“i A G“ 2 ) A ^(G“i A G“«) A ^(G “3 A G“^) A ^(G “3 A G“^) is: 
03 ^ 0i02, 04 A Oi, 04 A 02, 05 A 0i02, 05 A 0i04, 05 A O3O2, 05 A O3O4. 



Definition 13 (Closure). Let -< be a static priority. The closure of A is the 
least static priority containing A such that 

— if ai 02TO2 and 02 TO3 then oi 17121713; 

— if a am, then a m for m yf 1 . 

Example 3 . For {o ^ bc,b ^ od}, {o be, b ad, a acd, a 
cd, b bed, b cd}. 

Lemma 1. Lf for any ai € A, ai ^ m^ with m^ a monomial on A, then ai Oj 
for some ai € A. 

Proof. Omitted. 

Proposition 6 (Activity Preservation for Static Priorities). A static pri- 
ority A defines a deadlock-free restriction if and only if is irrefiexive. 

Proof, “if”: suppose that A’*' is irrefiexive. By definition, only top elements in A 
can be non-trivial monomials. Thus, A is acyclic, and all ascending chains in A 
are finite. Consider some deadlock-free transition system B = (A, A, {G“}aeA, 
{F°'}a^A), and let G = VaeA^'*- x be a state of B such that G(x), and 
let A' = {a e A I G“(x)}. As A is acyclic, max A' exists and is non-empty. It 
remains to show that some element of max A' is not dominated by any monomial 
in 2 ^ . Suppose that for any a* € A' there is some m^ G 2"^ , A m^. In that 
case, has a circuit by lemma 1, which contradicts the hypothesis. Thus, at 
least one action in max A' is maximal in A. 

“only if”: suppose that a A"*" a for some a G A. By construction of A+, 
this means that (A U m(A), a) contains a tree (A' U m(A'),^') with root a 
such that all leaves are monomials consisting only of the action a. Take B = 
(0, A, {G“}a6A, {0}aeA) with G^“ ) = true if a' G A', and G^“ ^ = false other- 
wise. By definition of /, all guards in B/V{B, -<) are false, whereas B is clearly 
deadlock- free. ■ 
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Example 4 - Consider the static priority ^ on the actions oi, 02, 03, 04 such that, 

02 ^ 0304, 03 ^ 0204, 04 ^ 0203. It is easy to see that is not irreflexive, 

thus ^ does not define a deadlock-free restriction. By elimination of 04, as in the 
proof of Lemma 1, we get: 02 0203, 03 0203 which gives by application 

of the second closure rule, 02 02, 03 03. Thus is not irrefiexive. 

Consider the slightly different static priority on the actions 04,02,03,04 
such that, 02 01O3O4, 03 02O4, 04 02O3. It can be checked that is 

irreflexive and thus deadlock-free and contains the chain 04 03 02 04. 

Clearly, is not irreffexive as 03 ^4 G“^. 04,04 ^4 G°''^ .a^. This example 
shows that for static priorities the use of the specific closure gives finer results 
than by using Proposition 3. 

3.2 Composition of Priorities 

Notice that given B and the predicate V{B,~<) depends on B. The property 
{{B , = {{B , does not hold in general. For instance, consider a 

system B and priorities ^ and such that 04 ^ 02 and 02 03 where 04, 02, 

03 are actions of B. If from some state of B the three actions are enabled then in 

{{B, -<),-<') only 03 is enabled while in {{B, both 04 and 03 are enabled. 

We define two composition operations on priorities and study composability 
results. 

Definition 14 (Composition of Priorities). Given two priorities and 
their composition is the operation 0 such that 0^ 0 0^= (0^ U 
Furthermore, if and 0^ are static priorities we define another composition 
operation, 0 such that 0^ 0 0^= (0^ U 0^)^. 

Proposition 7. The operations 0 and 0 are associative and commutative. 

Lemma 2. Let 0 = 0 ^ he an irreflexive closed static priority. Then, any non 
maximal action a is dominated by some monomial m on maximal actions. 

Proof. Omitted. 

Proposition 8 (Composability for Static Priorities). Given a transition 
system B and two static priorities 0^ and 0^, if 0^ U 0^=0^ 0 0^ then 

Proof. Let G“, (G“)', (G“)", and (G“)'" be the guards of action a in B, B/ 0^, 
{B/ -<^)/ and B/{^^ 0 0^), respectively. For some state x, let Aq = 
{a G 4I I G“(x)}, Ai = {a & A \ (G“)'(x)}, A2 = {a € A \ (G“)"(x)}, and 
^3 = {a G ^ I (G“)'"(x)}, respectively. Notice that A2 U A3 C 4I4 C Aq. We 
show that A2 = A3. 

If a G A2 then there is no monomial on Ag dominating a in and there is 
no monomial on A4 dominating a in Thus, either there is no monomial on 
Ag dominating a in U ^^=0^ 0 0^, and a G A3, or there is a monomial m 
on Ag such that a -<^ m. In the latter case, m = m'm" with m' a non-empty 
monomial on Ag\ A4, and m" a monomial on A4 (i.e., product of actions that are 
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maximal in Thus, for any factor Oi of m' there is a monomial nii on Aq (and 
by lemma 2, on Ai) such that Since U 0 0^, 

we have a(0^ U 0 ^)toi • • •rrikm" , and a ^ A 2 , which is in contradiction to the 
assumption. Thus, a G A 3 . 

Conversely, if a G 2I3, then a is not dominated by any monomial on ^0 in 
U . Thus, a is maximal among Aq and Ai in both priorities, and a G ^2- • 

Proposition 9 (Composability for Priorities). Given a transition system 
B and two priorities 0^, 0^, if U 0^=0^ © then ((i?, 0^),©^) ~ 

© ©^). 

Proof. Consider some state x, and let be the static priority defined by ©* 
at state x: aj C-j(x), i = 1,2. Notice that is irrefiexive 

whenever is irrefiexive. The proof follows that of proposition 8 for the 

static priorities ^nd state x. ■ 

Propositions 8 and 9 provide composability conditions, that is conditions 
guaranteeing commutativity of two restrictions defined by priorities. The fol- 
lowing proposition is easy to prove by using monotonicity properties © and the 
definitions of composition operations. It shows that the successive application of 
priority restrictions can be safely replaced by their composition. 

Proposition 10. For any transition system B and priorities we have 

— if then (B, 

— (i?, E U E Furthermore, for static 

priorities, (B, ~ {B,<^ © ©^). 

3.3 Safety and Deadlock-Freedom 

We present results relating deadlock-free control invariants to priorities. We show 
that priorities can be used to define any restriction corresponding to a deadlock- 
free control invariant. 

Given a transition system B and a predicate U, the restriction V{U) guar- 
antees the invariance (safety) for U in B/V{U), that is inv[B /V{U)]{U). Fur- 
thermore, if [/ is a control invariant then V{U) is a control restriction, that is a 
restriction that does not affect the guards of uncontrollable actions. As a rule, 
V (U) is not deadlock-free. We define for a predicate U, a priority ©[/ and study 
relationships between its restrictions and V{U). 

Definition 15. Given a state predicate U on a transition system, the associated 
priority <u is defined by <u= {prea{~^U) A prca' ([/)}(„, a')eA<=xyi- 

Property 2. The priority ©[/is transitively closed and irrefiexive and thus it 
defines a deadlock-free restriction. 

Proposition 11. For any transition system B and predicate U, B/V{U) E[/ 
(B,^u). Furthermore, if U is a deadlock-free invariant of B, B/V{U) ~[/ 

\b, ©[/). 
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Proof. As we consider B with initial set of states satisfying U we assume that 
all the guards of its actions are such that G“ =k U. Let’s verify that if (G“*)' 
is the restricted guard of action in then G“* AprCa^iU) =k (G“‘)'. 

We find (G“*)' = G“‘ A A prea,\u) A G“->) = G“* A 

hU) V ^prca^ (U)) = G“* A ^prCa^ i^U) V G“* A Aa^eA -^preaj (U) . 
Given that G“* A ^prCaA^U) = G“* AprCa^U), we have 
(G“0' = A preaAU) V G“* A Aa^aA^Prea^U). 

From this follows that B/V{U) Qu {B, Au)- 

If G is a deadlock- free invariant then for any guard G“% G“* =k G =k 
MajGAP'^^o.A^)- Thus, we have G“ A AajeA^P^^aA^) = Consequently, 

(G“*)' = G“* AprCaAU) which completes the proof. ■ 

A direct consequence of this proposition is that for any deadlock-free control 
invariant G, B/V{U) ~u {B, ~<u)- That is the effect of deadlock-free controllers 
can be modeled by restrictions induced by priorities. 

From this proof it also follows that the guards of B/V{U) and {B, Au) agree 
at deadlock-free states of B/V{U) in G. They may differ at deadlock states of 
B/V{U) where B is deadlock- free. In other words {B,Ajj) is a kind of “best 
deadlock-free abstraction” of B/V{U) under G. 

Example 5. We apply the previous proposition for B and G of Example 1. We 
show that {B,Au) behaves exactly as B' = B/V{U) from any state satisfying 
the deadlock-free control invariant G. 

We have prea^i^U) A pret^iU) = w > 0, preb^{^U) A prcb^iU) = w > 
1, prcbA^U) ApreaAU) = r > 0 and preaA^U) A prcbAU) = pretA^U) A 
prcaj (G) = false. This gives the priority 

<u= {ai {w > 0).b2,bi <u {w > 1).&2),&1 <u (r > 0).O2)}. It can be 
checked that (B, Au) is indeed equivalent to {B/V (G)). The computation of the 
restricted guards (G“^)' and (G^^)' gives 
(G“i)' = G“i A > 0 V = w = 0 and 

(G^iy = G*-! A > 1 V ^G^A A (^r > 0 V ^G^A = (w = 0) A (r = 0). 

The following propositions study relationships between safety and deadlock- 
free restrictions. 

Proposition 12. If U\, U 2 are two state predicates and Ajji, ^^6 cor- 
responding priorities, then B/V{Ui A U 2 ) E( 7 ia (/2 ® ^ 1 / 2 ) E( 7 iA (/2 

(G, AuiaU 2 )- 

Furthermore, i/GiAG 2 is a deadlock-free invariant then B /V{UiAU 2 ) —U 1 AU 2 
® AU2) —U1AU2 {B,~<UiaU 2 )- 

Proof. Omitted. 

This proposition says that {B,Aui ® ^^ 72 ) is an upper approximation of 
B/V{Ui A U 2 ). The following proposition shows an even stronger relationship 
between the two priority systems. 

Proposition 13. IfUi, U 2 are two deadlock-free invariants of B and Ajji ® -<U 2 
is irrefiexive then B/V{Ui A U 2 ) —U 1 AU 2 (B, 0 ^ 1 / 2 ) deadlock- free. 
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Proof. We have from B/V{Ui) ~Ui and B/V{U 2 ) 

® ^(/a) Ec/i {B,~<Ui U ^c/a) E(7i B/V{Ui) and {B,~<u^ 0 
{B,<Ui U ®(7a) Et/a B/V{U 2 ). This gives, {B,~<ij^ 0 ^Ui/\U 2 B/V{Ui) A 

V {U 2 ) — B /V{Ui A U 2 ) ■ From the previous proposition we get the result. ■ 

The following proposition provides for static priorities, a result similar to 
Proposition 11. It is very useful for establishing safety by using static priorities. 

Proposition 14. Given a state predicate U on a transition system B = (X, A, 
{G“}a6A,{i^na6A), let Ajj be a static priority such that Va € A . prCai^U) 
y m . a<vm ■ Then, inv[{B , <u)]{U) . 

Proof. By Definition 10 of the semantics of {B, Ajj)- ■ 

As shown in the following example, this proposition provides a means to 
ensure invariance of an arbitrary predicate U by static priorities. The choice of 
Ac/ is a trade-off between completeness and efficiency. Extreme choices are given 

by 



— a Ac/ AprCa' fU) yf false, which is a priority with singleton 

monomials only; the closure of this priority may easily be not irreflexive. 

— a Ac/ m 3x . (^prea{^U)){x.) A to = {o' | G“ (x)} which is the most 

fine-grained static priority ensuring invariance of U. 



4 Example 

We consider a robotic system controlled by the following processes: 

— 3 trajectory control processes TGi, TG 2 , TCrman. TC 2 is more precise 
and needs more resources than TCp, TC-inan is the process for manual 
operation. 

— 2 motion planners, MPi, MP 2 , MP 2 is more precise and needs more resources 
than MPi. 

We consider for each process P predicates P.halted and P.running such that 
P.halted = ^P.running. Each process P can leave states of P.halted (resp. 
P.running) by action P. start (resp. P.stop), as in figure 1. The robotic system 
must satisfy forever the following constraints: 

1. In order to ensure permanent control of the position and movements of 
the robot, at least one trajectory control process and at least one motion 
planner must be running at any time: (TG/.running V TG2.running V 
TG_TOon. running) A (MPi. running V MP2-running). 

2. In order to meet the process deadlines, the CPU load must be kept below a 
threshold, which excludes that both high-precision processes can be simul- 
taneously active: TG2. halted V MP2-halted. 
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Fig. 1. Transition system of a process 



The problem is to find a deadlock-free controller which restricts the behavior 
of the system so that the above requirement is met. A similar problem has been 
solved in [ 13 ] by using controller synthesis [ 12 ]. We propose a solution by finding 
an appropriate static priority. 

We put the global constraint to be satisfied as a predicate U in conjunctive 
form: U = (TGi. running V TC2. running V TCfman. running) A (MPi. running V 
MP2-running) A (TC2. halted V MP2-halted). 

Invariance of U requires the invariance of each one of the three conjuncts, 
disjunctions of predicates. We define the static priority -<ij in the following 
manner. 

For each conjunct D consider the critical configurations where only one literal 
of the disjunction is true. The priority -<jj prevents critical actions, that is actions 
that can turn this term to false, by keeping them dominated by safe actions 
enabled in the considered configuration. More formally, for each disjunction D, 
each critical action a (for which D A prea(^D) 7^ false) is dominated by the 
monomial consisting of the safe actions enabled in D. 

For example, take D = PGi. running V PC2. running V PCfman. running. 
Consider the critical configuration where PCi. running = true, PC2. running = 
false, and PC-man. running = false. Clearly, TC\.stop is a critical action for this 
configuration. Its occurrence can be prevented by the static priority TCi.stop -< 
PC2. start - TCjman.start. The monomial TC2. start - TCjman.start is the product 
of the safe actions enabled at this configuration. In this way, we compute the 
static priority -<u which guarantees invariance of U: 

PCi.stop -<jj PC2. start - PC-man. start 
PC2.stop -<jj PCi. start - PC-man. start 
PC_man. stop -<jj PCi. start - PC2. start 
MPi.stop ^(7 MP2. start 
MP2.stop A (7 MPi. start 
PC2. start A(7 MP2.stop 
MP2. start A(7 PC2.stop 

It is easy to see that is irreflexive. By Proposition 6, ~<u is a deadlock- 
free restriction. By Proposition 14 , U is an invariant of (PCi U PC2 U TC-manU 
MPi U MP 2 ,<u)- 



Priority Systems 327 



This approach can be applied to find deadlock-free control restrictions of arbi- 
trary systems of processes {Bi, . . . , B„} abstractly modeled as the deadlock-free 
transition system of figure 1, preserving a predicate U, boolean expression on 
atomic predicates running and halted. For example, U can express require- 
ments on the global system state such as: 

— a safety-critical process must not run unless a failure-handling process is 
running; 

— mutual exclusion between concurrently running processes, e.g., between a 
safety-critical and an untrusted process. 

We suppose U to be written as a conjunction of disjunctions 
U = f\ { \J i?j. running V \J Bj. halted) 

j&Ji jdJ'i 

where I, J{ and J' are index sets such that any conjunct has at least two atoms 
that are predicates on two different processes (this is always possible for any 
predicate U if we have at least two processes) . 

Invariance of U is equivalent to invariance of all of its conjuncts Dj. Consider 
the conjunct Viej i?;. running V \/;gj/ i?;. halted. As in the previous example, 
consider a critical configuration, that is, a configuration where only one literal 
is true. We distinguish two cases: 

— if that literal is iJj. running (thus j G Ji), then Bj.stop violates U from this 

configuration characterized by B/. halted A B;. running. 

This action can be prevented by the static priority 

Bj.stop A[/ B;. start • B/.stop 

In this relation, Bj.stop is dominated by the monomial consisting of the 
actions of the other processes involved in this configuration. 

— if the literal is Bj. halted (thus j € J'), then Bj. start violates U , and we apply 
a similar reasoning and get Bj. start A[/ Wi^j. B;. start • rii6j'\{j} Bj.stop. 

Let Ac/ be the union of the so defined priorities for all i G I. 

By definition of Ac/, for any disjunct Di of U, any critical action a is dom- 
inated by at least one monomial m{a,Di) = J([B/. start • f][ Bj.stop consist- 
ing of safe actions enabled in Bj. Thus, prCai^Di) =A /\aiem(a Di) ^ 
and preai^U) = prea{^ Di) = i^i^Di) = \! i^iPrCai^D^) 

\/iei /\aiem(a,Di)^°'*- proposition 14, U is an invariant of )• 

Notice that Ac/ is minimally restrictive, that is, only transitions violating the 
invariance of U are inhibited. 

Deadlock- freedom of ) is established by Proposition 14 if A j) is 

irrefiexive, which depends on the actual predicate U. 
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5 Discussion 

We present a framework for the incremental construction of deadlock-free sys- 
tems meeting given safety properties. The framework borrows concepts and 
basic results from the controller synthesis paradigm by considering a step in 
the construction process as a controller synthesis problem. Nevertheless, it does 
not directly address controller synthesis and other related computationally hard 
problems. Instead, it is based on the abstraction that the effect of the controller 
corresponding to a deadlock-free control invariant can be modeled by deadlock- 
free control restrictions. 

Priorities play a central role in our framework. They can represent any 
deadlock-free control restriction. They can be naturally used to model mutual 
exclusion constraints and scheduling policies [4,2]. They are equipped with very 
simple and natural composition operations and criteria for comp os ability. We 
provide an equational characterization of priorities and a sufficient condition for 
representing deadlock-free restrictions. Static priorities are solutions expressed 
as boolean expressions on guards for which a necessary and sufficient condition 
for deadlock- freedom is provided. 

The use of priority systems instead of simple transition systems is a key idea 
in our approach. Of course, any priority system is, by its semantics, equivalent 
to a transition system. Nevertheless, using such layered models offers numerous 
advantages of composability and compositionality: 

“ The separation between transition system (behavior) and priorities allows 
reducing global deadlock-freedom to deadlock-freedom of the transition sys- 
tem and a condition on the composed priorities. 

— The use of priorities to model mutual exclusion and scheduling policies in- 
stead of using transition systems leads to more readable and compositional 
descriptions [2]. 

— In [6,5] priority systems are used to define a general framework for com- 
ponent-based modeling. This framework uses a single associative parallel 
composition operator for layered components, encompassing heterogeneous 
interaction. Priorities are used to express interaction constraints. For systems 
of interacting components, we have proposed sufficient conditions for global 
and individual deadlock-freedom, based on the separation between behavior 
and priorities. 

Our work on priorities found application in generating schedulers for real- 
time Java applications [9]. This paper uses a scheduler synthesis algorithm that 
generates directly (dynamic) priorities. Another interesting application is the 
use of priorities in the IF toolset to implement efficiently run-to-completion 
semantics of the RT-UML profile [7]. 

Priority systems combine behavior with priorities, a very simple enforce- 
ment mechanism for safety and deadlock-freedom. This mechanism is powerful 
enough to model the effect of controllers ensuring such properties. They offer 
both abstraction and analysis for incremental system construction. Our theo- 
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retical framework can be a basis for the various approaches and practices using 
enforcement mechanisms in a more or less ad-hoc manner. 
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Abstract. In this paper we discuss the question which properties of 
a formally verified component are preserved when the component is 
changed due to an adaption to a new use. More specifically, we will 
investigate when a temporal logic property of an Object-Z class is pre- 
served under a modification or extension of the class with new features. 
To this end, we use the slicing technique from program analysis which 
provides us with a representation of the dependencies within the class 
in the form of a program dependence graph. This graph can be used to 
determine the effect of a change to the class’ behaviour and thus to the 
holding of a temporal logic formula. 



1 Introduction 

With the advent of component-based software engineering systems are more 
and more built from pre-fabricated components which are taken from libraries, 
adapted to new needs and assembled into a system. Furthermore, for the design 
of dependable systems formal methods are employed during the construction 
process to improve the degree of correctness and reliability. The combination 
of these two techniques — component-based design and formal methods — in 
system construction poses a large number of new research challenges which are 
currently very actively taken up. 

This paper studies one aspect arising in this area, based on the following 
scenario of a component-based construction. We assume that we have a library 
of components which are formally specified and proven correct with respect to 
certain requirements. During system construction components are taken from the 
library and (since they might not fully comply to their new use) are modified 
or even extended with new features. The question is then whether the proven 
properties are preserved under this specialisation and thus whether we can also 
get a re-use of verification results and not just of components. More specifically, 
given a component A (which will be a single class here) and its modification or 
extension C we are interested in knowing whether a property P holding for A 
still holds for C (see the following figure) . 
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Property P 



Property P ? 



Although the picture might suggest that the relationship between A and C 
is that of inheritance (since we use the specialisation arrow of UML) we are 
actually interested in a more general relationship: C may be any class which 
is constructed out of A, may it be by inheritance or by a simple change of the 
existing specification. 

As a first observation, it can be remarked that even a restriction to inheri- 
tance cannot ensure that properties are preserved: a subclass may differ from its 
superclass in any aspect and thus none of the properties holding for A might be 
preserved in C . Still, preservation of properties to subclasses is an important and 
intensively studied topic. Within the area of program verification, especially of 
Java programs, this question has already been tackled by a number of researchers 
[6,10,5]. In these approaches correctness properties are mainly formulated in 
Hoare logic, and the aim is to find proof rules which help to deduce subclass 
properties from superclass properties. In order to get correctness of these rules 
it is required that the subclass is a behavioural subtype [7] of the superclass. This 
assumption is also the basis of [14] which studies preservation of properties in an 
event-based setting with correctness requirements formulated as CSP processes. 

In this paper we lift this assumption (although also looking at subtypes as a 
special case) and consider arbitrary classes constructed out of existing classes. 
For convenience we will, however, often call the class C the subclass and A 
its superclass. Instead of employing restrictions on the subclass (in order to 
preserve properties) we will compute whether a property is preserved or not. This 
computation does not involve re-verification of the property but can be carried 
out on a special representation of the classes called program dependence graphs. 
Program dependence graphs carry all information about the dependencies within 
programs (or in our case, specifications) and thus can be used to determine 
the influence of a change or extension on proven properties. This technique 
is originally coming from program analysis where slicing techniques operating 
on program dependence graphs are used to reduce a program with respect to 
certain variables of interest. Slicing techniques (and a similar technique called 
cone-of-influence reduction) are also being applied in software and hardware 
model checking for reducing programs [4,9,1]. 

In our framework classes are not written in a programming language but are 
defined in a state-based object-oriented formal method (Object-Z [11,2]). Cor- 
rectness requirements on classes are formalised in a temporal logic (LTL [8]). 
As changes (specialisation) we allow the addition of attributes, the modification 
of existing methods and the extension with new methods. A comparable study 
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about inheritance of CTL properties is described in [15], however, not employ- 
ing the program dependence graphs of slicing which allow for a more succinct 
representation of the dependencies within specifications. 

The paper is structured as follows. In the next section we define the necessary 
background for our study. Section 3 studies property preservation for subtypes 
and section 4 introduces slicing as a more general technique for computing pre- 
served properties for arbitrary changes. Section 5 concludes. 

2 Background 

This section describes the background necessary for understanding the results: 
the definition of classes in Object-Z, the temporal logic LTL and a result showing 
that LTL-X properties are preserved under stuttering equivalence. Stuttering 
equivalence will be used to compare super- and subclasses. 

2.1 Class Definitions 

Classes are described in a formalism very close to Object-Z [11]^. Object-Z is an 
object-oriented extension of Z and thus a state-based specification technique. 

The following specification of a simple account is the running example for our 
technique. It specifies the state of an account (with a certain balance), its initial 
value and two methods for depositing and withdrawing money from the account. 
Methods are specified with enable and effect schemas describing the guard (to 
the execution of) and the effect of executing the method. For instance, since the 
account may not be overdrawn, the guard of Withdraw specifies that the amount 
of money to be withdrawn may not exceed the balance. The Z\-list of an effect 
schema fixes the set of variables which may be changed by an execution of the 
method. 

Account^ 



balance : Z 



Init 

balance = 0 



effect^Deposit 

A(balance) 
amount! : N 

balance' = balance + amount? 



enable^Deposit 
amount? : N 

true 



^ In fact, it is the Object-Z part of CSP-OZ specifications [3] (a formalism which inte- 
grates CSP with Object-Z). We nse this formalism since we are ultimately interested 
in answering the qnestion of property preservation for CSP-OZ. 
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enable- Withdraw _ 
amountl : N 

balance > amountl 



effect- Withdraw 

A(balance) 
amountl : N 

balance' = balance — amountl 



In our definitions we use the following non-graphical formulation of classes. 
Classes consist of attributes (or variables) and methods to operate on attributes. 
Methods may have input parameters and may return values, referred to as output 
parameters. We assume variables and input /output parameters to have values 
from a global set D. A valuation of a set of variables U is a mapping from V to 
D , we let Ry = {p ■ V ^ D} stand for the set of all valuations of V; the set of 
valuations of input parameters Inp and output parameters Out can be similarly 
defined. We assume that the initialisation schema precisely fixes the values of 
variables (i.e. is deterministic) in order to have just one initial state^. 

A class is thus characterised by 

— A set of attributes (or variables) V, 

— an initial valuation of V to be used upon construction of objects: I : V ^ D, 
and 

~ a set of methods (names) M with input and output parameters from a set 
of inputs Inp and a set of outputs Out. For simplicity we assume Inp and 
Out to be global. Each m G M has a guard enable^ Ry ^ Rinp ® 
(B are booleans) and an effect effects. '■ Ry y. Rinp ^ Ry x Rout- The 
guard specifies the states in which the method is executable and the effect 
determines the outcome of the method execution. 

A class will thus be denoted by ( V, I, (enablem) me m , {effectm) me m) or ( V, I, 
M) for short. We furthermore need to know the set of variables which are set and 
referenced by a schema: Set (enable _m) = 0, 5'et(ef f ect-m) are the variable 
appearing in the Z\-list of the effect schema and Ref (enable _m), Ref (effect^m) 
are those that syntactically appear in the schemas enable_m, ef f ect_m respec- 
tively. 

The semantics of a class is defined in terms of Kripke structures. 

Definition 1. Let AP be a nonempty set of atomic propositions. A Kripke 
structure K = (S,sq, — >,L) over AP consists of a finite set of states S, an 
initial state sq G ■S', a transition relation — > C S x S and a labelling function 
L-.S^2^P. 

The set of atomic propositions determines what we may observe about a 
state. Essentially there are two kinds of properties we like to look at: the values 
of variables and the availability of methods. Thus the atomic propositions APa 
that we consider for a class A = (V ,I , (enablcm) me m , (effectm)meM) are 



^ This assumption is not essential but more convenient. 
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~ V = d, V € V,d £ D and 

— enabled{m), m £ M. 

The Kripke structure semantics of a class definition is then defined as follows. 

Definition 2. The semantics of (an object of) a class A={V ^ I, {enablem)meM, 
{effectm)m^M) is the Kripke structure K = {S,sq, — !-,L) over APa with 

~ S = Rv , 

— So = I, 

— ^ — {(^5^ ) I 3 771 ^ AI ^ Pifi £ Rinp-i Pout € ROut • enablCjri^S j Pin) 

^ ^ Pin) — (s :Pout))^ 

— L{s) = {w = d I s{v) = d} U {enabled(m) \ 3 pin £ Rinp ■ enablcmis, pm)}- 

Since the atomic propositions do not refer to inputs and outputs of methods, 
they are not reflected in the semantics. However, inputs and outputs can be 
embedded in the state and thus can be made part of the atomic propositions 
(see e.g. [12]). 

Figure 1 shows the Kripke structure (without L) of class Account^. The num- 
bers indicate the values of attribute balance. All states satisfying balance < 0 are 
unreachable. The upper arrows correspond to executions of Deposit^ the lower 
to those of Withdraw. 




Fig. 1. Kripke structure of class Accounto 

Furthermore, we have to fix the kind of changes allowed in subclasses. We do 
not allow to remove methods, but methods can be arbitrarily modified as well 
as new methods and variables be introduced. 

Definition 3. Let A and C be classes. C is a specialisation of A if Va C Vc, 
Ma C Me and Ic \ Va= ^a- 

2.2 LTL Formulae 

The temporal logic which we use for describing our properties on classes is linear- 
time temporal logic (LTL) [8]. 

Definition 4. The set of LTL formulae over AP is defined as the smallest set 
of formulae satisfying the following conditions: 

— p £ AP is a formula, 

— if are formulae, so are and ipi V ip 2 , 

— if ip is a formula, so are Xip (Next), □(/? (Always), Oip (Eventually), 

— if ipi,ip 2 are formulae, so is (pi U ip 2 (Until). 
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As usually, other boolean connectives can be derived from ^ and V. The 
next-less part of LTL is referred to as LTL-X. LTL formulae are interpreted on 
paths of the Kripke structure, and a formula holds for the Kripke structure if it 
holds for all of its paths. 

Definition 5. Let K = {S,s, — >,L) be a Kripke structure. A finite or infinite 
sequence of states tt = sqSiS 2 ... is a path of K iff s = sq and (si, Si+i) G — > 
for all 0 < i. For a path tt = sqSiS 2 ■■■ we write 7t[z] to stand for Si and tt* to 
stand for SiSi+iSi +2 ■ ■ ■■ The length of a path tt, ffir, is defined to be the number 
of states (in case of a finite path) or oo (in case of an infinite path). 

Usually, paths are assumed to be always infinite (and LTL formulae inter- 
preted on infinite paths). We deviate from that because objects may also exhibit 
finite behaviour: if no methods are called from the outside anymore, the object 
just stops. This has, however, consequences on the holding of liveness properties: 
since for instance sq alone is also a path, a liveness property can only hold if 
it already holds in the initial state. Thus we essentially treat safety here. Live- 
ness can be treated if we additionally make some fairness assumptions on the 
environment of an object (see conclusion for a discussion). 

Definition 6. Let K = (S,so, — >,L) be a Kripke structure and ip an LTL for- 
mula, both over AP. K satisfies (p (K \= p) iff tt \= p holds for all paths tt of 
K , where tt \= p is defined as follows: 

~ T^\=P iff P & '^^(7t[0]), 

— TT \= ~^p iff not TT \= p, 

— tt'^ pi\J P 2 iffTT\=pi or tt\= P 2 , 

— TT \= X p iff fflT > 1 A 7T^ \= T, 

— 7T 1= Op iffyi,0 < i < ffTT : 7T* 1= (/?, 

— TT \= Op iff 3i,0 < i < ffiT : 7T* 1= (/?, 

— TT \= Pi U p 2 iff^k,0<k< ffTT : TT^ \= p 2 and ^ j,0 < j < k : tt^ \= Ti- 

For our bank example we for instance have the following properties. The 
Kripke structure KAccounto of Account^ fulfills 

Ti Account^ ^ O (^balance P 0) , 

KAccounto h ^{enabled (Deposit)) . 



2.3 Stuttering Equivalence 

For showing that properties are preserved under change, or more particular, 
that a certain property still holds for a subclass, we will later compare super- 
and subclasses according to a notion of equivalence called stuttering equivalence. 
Stuttering equivalence is defined with respect to some set of atomic proposition 
and roughly says that on these proposition of interest two Kripke structures have 
an equivalent behaviour. All transitions changing propositions outside those of 
interest are regarded as stuttering steps. 
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Definition 7 . Two infinite paths tt = sq'SiS2 • • ■ o,nd p = rorir2 . . . are stuttering 
equivalent wrt. a set of atomic propositions AP (tt ^ap p) if there are two 
sequences of indices 0 = ig < < «2 < • ■ ■ and 0 = jo < ji < J2 < ■ • ■ such that 

for every k > 0 



L{s,,) nAP = L{s,,+i) nAP = --- = L{s,,.,-i) nAP = 

L(r,J n = P(r,,+i) nAP = --- = H AP 

A finite path tt = sq ... Sn is stuttering equivalent to an infinite path p if its exten- 
sion with an infinite number of repetitions of the last state, i.e. sq • ■ ■ SnSnSn ■ • ■, 
is stuttering equivalent to a. (And similarly for two finite paths.) 

Intuitively, the sequences are equivalent if they can be divided into blocks in 
which atomic propositions stay stable and the j-th block in tt has the same set 
of propositions from AP as the i-th block in p (illustrated in Figure 2). 




Fig. 2 . Stuttering equivalent sequences 



Definition 8 . Let Ki = {Si,SQAi — he Kripke structures over 
AP\,AP2, respectively. Ki and K2 are stuttering equivalent with respect to a set 
of atomic propositions AP C APi n AP2 (Ki psap K2) iff 

— initial states agree on AP : 



Li{soa) n AP — ^2(50, 2) n AP , 

~ for each path tt in Ki starting from sg.i there exists a path tt' starting from 
So, 2 such that tt t^ap tt', 

— and vice versa, for each path tt in K2 starting from sq,2 there exists a path 
tt' starting from sq,i such that tt ~ap 'p' ■ 

Stuttering equivalent Kripke structures satisfy the same set of LTL-X prop- 
erties [1]. The Next operator has to be omitted since stuttering may introduce 
additional steps in one structure which have no counterpart in the other. 

Theorem 1 . Let p he an LTL-X formula over AP and K\, K2 Kripke struc- 
tures. If K\ thap K2 then 



iff K 2 \=(fi . 
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3 Property Preservation 

Now that we have set the ground, we have another look at our example and 
make two changes to the class. The first is an extension of the class, we add one 
new method for balance checking. Here, we use inheritance to avoid having to 
write the whole specification again. 

Aeeounti 

inherit Accountet 

enab\e_CheckBalance 

true 



effect_CheckBalance 

ball : Z 

ball = balance 



The second change is a modification, we modify the account such that it 
allows overdrawing up to a certain amount. Here, we inherit all parts but the 
definition of Withdraw which is overwritten by the new definition. 



Account 2 

inherit Account) 

modifies Withdraw 



overdraft : N 



Init 

r overdraft = 1000 



enable- Withdraw 

amount? : N 

balance — amount? > 
— overdraft 



effect- Withdraw _ 
A{balance) 
amount? : N 

balance' = balance- 
amount? 



The question is then which of our properties are preserved, i.e. which of the 
following questions can be answered with yes. 

^Aeeounti 0(^balance ^ 0 )? 

KAccounti h 0{enabled{Deposit))? 

K Account^ 1= ^{balance > 0)? 

KaccouuIa h 0{enabled{Deposit))? 

For this simple example, the answers are easy. What we aim at is, however, 
a general technique which answers such questions. In general, these two changes 




338 



H. Wehrheim 



are of two different types. The changed class can be a subtype of the original class 
(and then all properties are preserved) or it is not (and then a more sophisticated 
technique has to be applied to find out whether a property is preserved) . 

In this section, we deal with the first, more simple case. The second case is 
dealt with in the next section. A subtype can be seen as a conservative extension 
of a class: new methods may read but may not modify old variables. 

Definition 9. Let A = {Va,Ia, Ma) and C = (Vc,Ic,Mc) be two classes, C 
a specialisation of A. C is a subtype of A iff the following conditions hold: 

— y m € Me \ Ma: Setc {ef feet _m) C Vc \ Va (ni only modifies new vari- 
ables), 

— y m G Ma '■ enable);) = enable)) A effect)) = effect)) ( old methods not modi- 
fied). 

Subtypes inherit all properties as long as they are only talking about propo- 
sitions over the old attributes and methods. 

Theorem 2. Let C , A be classes, C a subtype of A. Let furthermore AP be the 
set of atomic propositions over Va and Ma- For all LTL-X formulae ip over AP 
we then have 

A'^ip C 1= (/? . 

In fact, the implication also holds in the reverse direction. The proof proceeds 
by showing that C and A are stuttering equivalent. The stuttering steps in C 
are those belonging to executions of the new methods: they do not change old 
attributes and thus do not affect AP. The proof can be found in an extended 
version of this paper. 

Coming back to our example, Accounti is a subtype of Accounto: CheckBalance 
only references balance but does not modify it. Hence both properties are pre- 
served: 



dy Accounti ^{balance P 0 ) 

KAccounti h 0(enabled{Deposit)) 



4 Slicing 

In this section we look at the more general case, where the modifications do not 
lead to subtypes. For this case, we cannot get one general result but have to 
specifically look at the changes made and the properties under interest. 

The technique we use for computing whether a property is preserved under a 
specific change is the slicing technique of program analysis [13]. In program ana- 
lysis slicing is originally used for debugging and testing, and answers questions 
like the following: ’’given a variable v and a program point p, which part of 
the program may influence the value of v at pT" . Here, we like to extract a 
similar kind of information about our changes: ’’given some propositions and 
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some change, does it influence the value of these propositions?”. Technically, 
slicing operates on graphs which contain information about the dependencies 
within a program, so called program dependence graphs (PDG). A similar graph 
is now built for Object-Z classes. It starts from the control flow graph (CFG) of 
a class (depicted in Figure 3), which contains 

— one node no labelled Init, 

— one node njjo labelled DO (nondeterministic choice), 

— for every method m two nodes and neff_m labelled enable_m and 

ef f ect_?7i. 



Init 




Fig. 3. Control flow graph of a class 

The program dependence graph is obtained from this graph by erasing all 
arrows and adding new ones corresponding to the control and data dependencies 
of the class. Formally, 

Definition 10. A program dependence graph (PDG) of a class specification 
( F, I , M) is a graph G = (A, Z,'^, ^) with 

— K = {no,njjo} U {nen_m I m € M} U {neff „i \ m G M} a set o/ nodes, 

— I a labelling function with 



I : no I— *■ Init 

riDO DO 

neri_m enable_77i 

nf,ff_m > effect_m 

— Q K X K the data dependence edges defined by 

n n' iff 3x G V \ x G Set{l{n)) and x G Ref{l{n')) and n > 

— >—fCKxK the control dependence edges defined by 

n ^ n' iS 3m G M : l{n) = enable_?7i and l{n') = ef f ect_?7i . 

Here, we take Set{DO) = Ref (DO) = 0. For class Accounto this gives rise 
to the graph shown in Figure 4. 
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Init 




ena.hle_Deposit 

1/ f 

effect-Beposit 



enable. 



Withdraw 



1 % 

effect-Withdraw 




=* = data dependency 
»- = control dependency 

Fig. 4. PDG of class Accounts 

For computing whether a property of A is preserved in G, we build a PDG 
including methods and dependencies of both A and C. In this POGyi^c we next 
determine the forward slice of all modified or new methods (where we say that 
Init is modified if it assigns new values to variables from A) . The forward slice of 
a set of nodes N is the part of the graph which is forward reachable from nodes 
in N via data or control dependencies. 

Definition 11. Let C, A he classes, C a specialisation of A. Let furthermore 
N he the nodes belonging to methods which are changed or new in C , i.e. 

iV = {n I {l{n) G {enable[m], effect_m | m G Me \ Ma\) V 

( 3 m S Ma '■ l{n) = enable_?7i A enable^ yf enable^) V 

( 3 m S Ma '■ l{n) = eff ect_?7i A effectff yf effect^)} 

The forward slice of N is the set of nodes in PDGa,c which are forward 
reachable from N , i.e. 

fs{N) = {n' G K \ 3n G N : n{'^ U ^YpdGa.c'^'^ 

The forward slice of N is the part of the class which is directly or indirectly 

influenced by the changes. The atomic propositions appearing in this part might 
be changed. We let AP^ denote the atomic propositions over variables or meth- 
ods in the forward slice of N. 

APf] = {v = d \ V G Vc \ V A^ 3n G fs{N) : v G Setc{l{n)) U 6'et^(Z(n))} 
U {enabled{m) | 3 n € fs{N) : l{n) = enable_?7i} 

Since these atomic propositions are potentially affected by the change, a 
formula talking about them might not hold in the subclass anymore. However, 
if a formula does not use propositions in APff then it is preserved. 
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Theorem 3. Let A, C he classes, N the set of methods changed or new in C . 
If if is an LTL-X formulae over AP \ APf] , then the following holds: 

A\=ip C \= ip . 



Init 



DO 



enahle^Deposit 

■1/ V 

effect_Deposit 



enable 



^^ithdraw 



Y ^ 

effect _Withdraw 




Fig. 5. PDG of Accounto, Account 2 



The proof again proceeds by showing that Ka and Kc are stuttering equiv- 
alent wrt. AP \ APf] and is included in an extended version. Since they are 
stuttering equivalent the implication in the theorem holds in the reverse direc- 
tion as well. 

For our example, the PDG for Account^, Account 2 is depicted in Figure 5. 
The set of changed methods N is { Withdraw}. Nodes not in the forward slice 
of Withdraw are {Init, DO, ena.hle_Deposit}. The variable balance is set by a 
method in the forward slice, but enable_Deposjt is not in the forward slice. 
Hence, concerning our properties, we know that one of them is preserved: 

KAccount 2 1= 0{enabled{Deposit)) 

but for the question KAccount^ 1= FI(6aZance > 0)? we get no answer (and in fact 
this property does not hold anymore). 

The case of changes leading to subtypes can be seen as one particular instance 
of this more general result: for subtypes we know by definition that the forward 
slice (of the new methods) will only contain new methods and thus affects only 
new variables. Hence, the proof of Theorem 3 can be seen as an alternative way 
of proving Theorem 2. 

The PDG of Account^, Accounti is depicted in Figure 6. As can be seen, in 
the forward slice of CheckBalance there is only CheckBalance. 



5 Conclusion 

This work is concerned with the re-use of verification results of classes. Given 
a verified class the technique presented in this paper can be used to determine 
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Init 




ena.hle_Deposit 

Y ---- 

effect-Deposit 



■.Withdraw 



enable. 



V -A 

effect-Withdraw 



ena.hle_CheckBalance 

V 

effect-CheckBalance 



Fig. 6. PDG of Accounto, Accounti 

whether some specific property is preserved under a change made to the class. 
The technique relies on the representation of the dependencies of a class specifi- 
cation in a program dependence graph. On this graph it is possible to determine 
the effect of changes on the behaviour of a class. As a special case we looked 
at changes inducing subtypes in which all properties (talking about the original 
class) are preserved. 

So far, this technique considers a single class only. It could be extended to 
larger systems either by combining it with compositional verification techniques 
(e.g. for Object-Z [16]), or by constructing a program dependence graph of the 
whole system. The latter could be achieved by combining program dependence 
graphs of the individual objects through a special new dependency arc reflect- 
ing the call structure between objects (possibly following approaches for slicing 
programs with procedures). 

Another limitation of the work presented here concerns the treatment of 
liveness properties. The inclusion of finite paths of a Kripke structure into the 
interpretation of LTL formulae lead to a restriction to safety properties. There 
are a number of ways of avoiding this limitation. One way would be to make 
certain assumptions about the environment of an object in that it infinitely often 
calls certain methods. These set of methods can be used as a fairness constraint 
on the behaviour of an object. The interpretation of LTL formulae can then be 
restricted to fair paths. If the fairness constraint for the subclass is the same as 
that for the superclass preservation of properties can be achieved. 

As future work, we like to extend the technique presented here to integrated 
specification formalisms which allow for the modelling of different viewpoints in 
different formal methods, as for instance CSP-OZ [3]. 
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Abstract. Attack graphs depict ways in which an adversary exploits system vul- 
nerabilities to achieve a desired state. System administrators use attack graphs 
to determine how vulnerable their systems are and to determine what security 
measures to deploy to defend their systems. In this paper, we present details of 
an example to illustrate how we specify and analyze network attack models. We 
take these models as input to our attack graph tools to generate attack graphs au- 
tomatically and to analyze system vulnerabilities. While we have published our 
generation and analysis algorithms in earlier work, the presentation of our example 
and toolkit is novel to this paper. 



1 Introduction 

As networks of hosts continue to grow, it becomes increasingly more important to auto- 
mate the process of evaluating their vulnerability to attack. When evaluating the security 
of a network, it is rarely enough to consider the presence or absence of isolated vulnera- 
bilities. Large networks typically contain multiple platforms and software packages and 
employ several modes of connectivity. Inevitably, such networks have security holes that 
escape notice of even the most diligent system administrator. 

1.1 Vulnerability Analysis and Attack Graphs 

To evaluate the security of a network of hosts, a security analyst must take into account the 
effects of interactions of local vulnerabilities and find global security holes introduced 
by interconnection. A typical process for vulnerability analysis of a network is shown in 
Figure 1. First, scanning tools determine vulnerabilities of individual hosts. Using this 
local vulnerability information along with other information about the network, such as 
connectivity between hosts, the analyst produces an attack graph. Each path in an attack 
graph is a series of exploits, which we call actions, that leads to an undesirable state. An 
example of an undesirable state is a state where the intruder has obtained administrative 
access to a critical host. 

A typical result of such efforts is a floor-to-ceiling, wall-to-wall “white board” attack 
graph, such as the one produced by a Red Team at Sandia National Labs for DARPA’s 
CC20008 Information battle space preparation experiment and shown in Figure 2. Each 
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Attack Graph 



Fig. 1. Vulnerability Analysis of a Network 



box in the graph designates a single intruder action. A path from one of the boxes at the 
top of the graph to one of the boxes at the bottom is a sequence of actions corresponding 
to an attack scenario. At the end of any such scenario, the intruder has broken the network 
security in some way. The graph is included here for illustrative purposes only, so we 
omit the description of specific details. 

Attack graphs can serve as a useful tool in several areas of network security, including 
intrusion detection, defense, and forensic analysis. System administrators use attack 
graphs for the following reasons: 

- To gather information: Attack graphs can answer questions like “What attacks is 
my system vulnerable to?” and “From an initial configuration, how many different 
ways can an attacker reach a final stale to achieve his goal?” 

- To make decisions: Attack graphs can answer questions like “Which set of actions 
should I prevent to ensure the attacker cannot achieve his goal?” or “Which set of 
security measures should I deploy to ensure the attacker cannot achieve his goal?” 

1.2 Prior Work and Contributions of this Paper 

In practice, attack graphs, such as the one shown in Figure 2, are drawn by hand. In 
earlier work, we show how we can use model checking techniques to generate attack 
graphs automatically [11, 17]. Our techniques guarantee that attack graphs are sound 
(each scenario depicted is a true attack), exhaustive (no attack is missed), and succinct 
(only states and state transitions that participate in an attack are depicted) [16]. 

In earlier work, we also have presented algorithms for analyzing attack graphs that 
answer questions such as those posed above [17, 9, 10]. For example, to help system 
administrators determine how best to defend their system, we cast the decision-making 
questions in terms of finding a minimum set of actions to remove (or minimum set of 
measures to deploy) to ensure the attacker cannot achieve his goal. We reduce this NP- 
complete problem to the Minimum Hitting Set problem [16], which can be reduced to 
the Minimum Set Cover problem [2], and we then use standard textbook algorithms to 
yield approximate solutions [3]. 
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Fig. 2. Sandia Red Team Attack Graph 
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In this paper, we present the complete details of an example. We use this example to 
illustrate: 

- How we specify network attack models; 

- The results of our automatic attack graph generation algorithms; 

- The results of our minimization analyses; 

- How to use our attack graph toolkit, including how we integrated tools from external 
sources with ours. 

The presentation of this example and our toolkit is novel to this paper. 

In Sect. 2 we give general definitions for attack models and attack graphs. Section 3 
narrows the definitions specifically to the domain of network security. Section 4 illus- 
trates the definitions with a small example network. Section 5 focuses on the practical 
aspects of building a usable attack graph tool. We discuss several approaches to collect- 
ing the data necessary to build the network model. Finally, we review related work in 
Sect. 6. 



2 Attack Models and Graphs 

Although our primary interest is in multi-stage cyber-attacks against computer networks, 
we define attack graphs abstractly with respect to models where agents attack and defend 
a complex system. 

Definition 1. An attack model is a finite automaton M = (S, r, sq), where S is a set of 
states, T C S X S is a transition relation, and sq G S is an initial state. The state space 
S represents a set of three agents X = {E, D,T}. Agent E is the attacker, agent D is 
the defender, and agent N is the system under attack. Each agent i £X has its own set 
of possible states Si, so that S = Xi^jSi. 

Definition 2. A finite execution of an attack model M = {S, r, sq) ^ a finite sequence of 
states OL = sqSi . . . Sn ,such that for all 0 < i < n, {si, Si+i) G r. An infinite execution 
of an attack model M = (S', r, Sq) infinite sequence of states /3 = SqSi . . . s„ . . ., 
such that for all i > 0, (sj, Sj+i) G r. 

With each agent z G X we associate a set of actions Ai , so that the total set of actions 
in the model is A = The single root state sq represents the initial state of 

each agent before any action has taken place. In general, the attacker’s actions move 
the system “toward” some undesirable (from the system’s point of view) state, and the 
defender’s actions attempt to counteract that effect. For instance, in a computer network 
the attacker’s actions would be the steps taken by the intruder to compomise the network, 
and the defender’s actions would be the steps taken by the system administrator to disrupt 
the attack. 

The specifics of how each agent is represented in an attack model depend on the type 
of the system that is under attack. In Sect. 3 we specify the agents more precisely for 
network attack models. Sheyner presents a more formal definition of attack models in 
his Ph.D. thesis [16]. 
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An attack model is a general formalism suitable for modeling a variety of situations. 
The system under attack can be virtually anything: a computer network under attack by 
hackers, a city under siege during war, an electrical grid targeted by terrorists, etc. The 
attacker is an abstract representation of a group of agents who seek to move the system to 
a state that is inimical to the system’s interests. The defender is an agent whose explicit 
purpose, in opposition to the attacker, is to prevent this occurrence. The system itself is 
oblivious to the fact that it is under attack. It goes through its normal routine according 
to its purpose and goals regardless of the actions of the active agents. 

Abstractly, an attack graph is a collection of scenarios showing how a malicious agent 
can compromise the integrity of a target system. With a suitable model of the system, we 
can use model checking techniques to generate attack graphs automatically [11,17, 16]. 
In this context, correctness properties specify the negation of the attacker’s goal: an 
execution is correct with respect to the property if the attacker does not achieve his goal 
for that execution. We call such properties security properties. An example of a security 
property in a computer network would be a statement like “the intruder cannot get root 
access on the web server.” 

Definition 3. Given an attack model M, a security property P is a subset of the set 
L{M) of executions of M. 

Definition 4. An execution a G L{M) is correct with respect to a security property P 
ijf a £ P. An execution a is failing with respect to P [violates P) iff a ^ P. 

We say that an attack model M satisfies a security property P if it does not have 
any failing executions (that is, if L{M) C P). If, however, M does have some failing 
executions, we say that the set of such executions makes up an attack graph. 

Definition 5. Given an attack model M and a security property P, an attack graph of 
M with respect to P is the set L{M)\P of failing executions of M with respect to P. 

For the remainder of this paper, we restrict the discussion to attack graphs comprised 
of finite executions only. For a more comprehensive treatment of finite and infinite failing 
executions we refer the reader to Sheyner [16]. 



3 Network Attack Graphs 

Network attack graphs represent a collection of possible penetration scenarios in a com- 
puter network. Each penetration scenario is a sequence of actions taken by the intruder, 
typically culminating in a particular goal — administrative access on a particular host, ac- 
cess to a database, service disruption, etc. For appropriately constructed network models, 
attack graphs give a bird’s-eye view of every scenario that can lead to a serious security 
breach. 

3.1 Network Attack Model 

A network attack model is an attack model where the system iV is a computer network, 
the attacker Ei is a malicious agent trying to circumvent the network’s security, and the 




Tools for Generating and Analyzing Attack Graphs 



349 



defender D represents both the system administrator(s) and security software installed on 
the network. A state transition in a network attack model corresponds to a single action 
by the intruder, a defensive action by the system administrator, or a routine network 
action. 

Real networks consist of a large variety of hardware and software pieces, most of 
which are not involved in cyber attacks. We have chosen six network components relevant 
to constructing network attack models. The components were chosen to include enough 
information to represent a wide variety of networks and attack scenarios, yet keep the 
model reasonably simple and small. The following is a list of the components: 

1 . //, a set of hosts connected to the network 

2. C, a connectivity relation expressing the network topology and inter-host reachabil- 
ity 

3. T, a relation expressing trust between hosts 

4. /, a model of the intruder 

5. A, a set of individual actions (exploits) that the intruder can use to construct attack 
scenarios 

6. Ids, a model of the intrusion detection system 

We construct an attack model M based on these components. Table 1 defines each 
agent z’s state Si and action set Ai in terms of the network components. This construction 
gives the security administrator an entirely passive “detection” role, embodied in the 
alarm action of the intrusion detection system. For simplicity, regular network activity 
is omitted entirely. 



Table 1. Network attack model 



Agent i G T 


Si 


Ai 


E 


I 


A 


D 


Ids 


{alarm} 


N 


H xC xT 


0 



It remains to make explicit the transition relation of the attack model M. Each 
transition (si, S 2 ) G t is either an action by the intruder, or an alarm action by the 
system administrator. An alarm action happens whenever the intrusion detection system 
is able to flag an intruder action. An action a G A requires that the preconditions of 
a hold in state si and the effects of a hold in S 2 - Action preconditions and effects are 
explained in Sect. 3.2. 

3.2 Network Components 

We now give details about each network component. 

Hosts. Hosts are the main hubs of activity on a network. They run services, process 
network requests, and maintain data. With rare exceptions, every action in an attack 
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scenario will target a host in some way. Typically, an action takes advantage of vulnerable 
or misconfigured software to gain information or access privileges for the attacker. 
The main goal in modeling hosts is to capture as much information as possible about 
components that may contribute to creating an exploitable vulnerability. 

A host h G H is a tuple (id, svcs, sw, vuls), where 

- id is a unique host identifier (typically, name and network address) 

- svcs is a list of service name/port number pairs describing each service that is active 
on the host and the port on which the service is listening 

- sw is a list of other software operating on the host, including the operating system 
type and version 

- vuls is a list of host-specific vulnerable components. This list may include installed 
software with exploitable security flaws (example: a setuid program with a buffer 
overflow problem), or mis-configured environment settings (example: existing user 
shell for system-only users, such as ftp) 

Network Connectivity. Following Ritchey and Ammann [ 15 ], connectivity is expres- 
sed as a ternary relation C C H x H x P, where P is a set of integer port numbers. 
C{hi, Ii2,p) means that host /12 is reachable from host hi on port p. Note that the 
connectivity relation incorporates firewalls and other elements that restrict the ability of 
one host to connect to another. Slightly abusing notation, we say R(hi, /12) when there 
is a network route from hi to /12. 

Trust. We model trust as a binary relation T C H x H, where T(hi, /12) indicates that 
a user may log in from host h2 to host hi without authentication (i.e., host hi “trusts” 
host /12). 

Services. The set of services S' is a list of unique service names, one for each service 
that is present on any host on the network. We distinguish services from other software 
because network services so often serve as a conduit for exploits. Furthermore, services 
are tied to the connectivity relation via port numbers, and this information must be 
included in the model of each host. Every service name in each host’s list of services 
comes from the set S. 

Intrusion Detection System. We associate a boolean variable with each action, ab- 
stractly representing whether or not the IDS can detect that particular action. Actions are 
classified as being either detectable or stealthy with respect to the IDS. If an action is de- 
tectable, it will trigger an alarm when executed on a host or network segment monitored 
by the IDS; if an action is stealthy, the IDS does not see it. 

We specify the IDS as a function ids: H x H x A ^ {d, s, 6 }, where ids(hi, 
h2,a) = d if action a is detectable when executed with source host hi and target host 
^2; ids(hi, /i2, a) = j if action a is stealthy when executed with source host hi and target 
host /12; and ids(hi, h2,a) = b if action a has both detectable and stealthy strains, and 
success in detecting the action depends on which strain is used. When hi and /12 refer to 
the same host, ids(hi, h2,a) specifies the intrusion detection system component (if any) 
located on that host. When hi and h,2 refer to different hosts, ids(hi, /12, a) specifies the 
intrusion detection system component (if any) monitoring the network path between hi 
and /i2. 
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Actions. Each action is a triple (r, hs,ht), where hg G H is the host from which the 
action is launched, ht G H is the host targeted by the action, and r is the rule that 
describes how the intruder can change the network or add to his knowledge about it. A 
specification of an action rule has four components : intruder preconditions, network pre- 
conditions, intruder effects, and network effects. The intruder preconditions component 
places conditions on the intruder’s store of knowledge and the privilege level required 
to launch the action. The network preconditions specifies conditions on target host state, 
network connectivity, trust, services, and vulnerabilities that must hold before launching 
the action. Finally, the intruder and network effects components list the action’s effects 
on the intruder and on the network, respectively. 

Intruder. The intruder has a store of knowledge about the target network and its users. 
The intruder’s store of knowledge includes host addresses, known vulnerabilities, user 
passwords, information gathered with port scans, etc. Also associated with the intruder 
is the function plvl: Hosts {none, user, root}, which gives the level of privilege that 
the intruder has on each host. For simplicity, we model only three privilege levels. There 
is a strict total order on the privilege levels: none < user < root. 

Omitted Complications. Although we do not model actions taken by user services for 
the sake of simplicity, doing so in the future would let us ask questions about effects of 
intrusions on service quality. A more complex model could include services provided 
by the network to its regular users and other routine network traffic. These details would 
reflect more realistically the interaction between intruder actions and regular network 
activity at the expense of additional complexity. 

Another activity worth modeling explicitly is administrative steps taken either to 
hinder an attack in progress or to repair the damage after an attack has occurred. The 
former corresponds to transitioning to states of the model that offer less opportunity for 
further penetration; the latter means “undoing” some of the damage caused by successful 
attacks. 



4 Example Network 

Figure 3 shows an example network. There are two target hosts, Windows and Linux, 
on an internal company network, and a Web server on an isolated “demilitarized zone” 
(DMZ) network. One firewall separates the internal network from the DMZ and another 
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Fig. 3. Example Network 
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firewall separates the DMZ from the rest of the Internet. An intrusion detection system 
(IDS) watches the network traffic between the internal network and the outside world. 

The Linux host on the internal network is running several services — Linux “I Seek 
You” (LICQ) chat software, Squid web proxy, and a Database. The LICQ client lets 
Linux users exchange text messages over the Internet. The Squid web proxy is a caching 
server. It stores requested Internet objects on a system closer to the requesting site than 
to the source. Web browsers can then use the local Squid cache as a proxy, reducing 
access time as well as bandwidth consumption. The host inside the DMZ is running 
Microsoft’s Internet Information Services (IIS) on a Windows platform. 

The intruder launches his attack starting from a single computer, which lies on the 
outside network. To be concrete, let us assume that his eventual goal is to disrupt the 
functioning of the database. To achieve this goal, the intruder needs root access on the 
database host Linux. The hve actions at his disposal are summarized in Table 2. 

Each of the five actions corresponds to a real-world vulnerability and has an entry in 
the Common Vulnerabilities and Exposures (CVE) database. CVE [22] is a standard list 
of names for vulnerabilities and other information security exposures. A CVE identifier 
is an eight-digit string prehxed with the letters “CVE” (for accepted vulnerabilities) or 
“CAN” (for candidate vulnerabilities). 



Table 2. Intruder actions 



Action 


Effect 


Example CVE ID 


IIS buffer overflow 


remotely get root 


CAN-2002-0364 


Squid port scan 


port scan 


CVE-2001-1030 


LICQ gain user 


gain user privileges remotely 


CVE-2001-0439 


scripting exploit 


gain user privileges remotely 


CAN-2002-0193 


local buffer overflow 


locally get root 


CVE-2002-0004 



The IIS buffer overflow action exploits a buffer overflow vulnerability in the Mi- 
crosoft IIS Web Server to gain administrative privileges remotely. 

The Squid action lets the attacker scan network ports on machines that would other- 
wise be inaccessible to him, taking advantage of a misconfigured access control list in 
the Squid web proxy. 

The LICQ action exploits a problem in the URL parsing function of the LICQ software 
for Unix-flavor systems. An attacker can send a specially-crafted URL to the LICQ client 
to execute arbitrary commands on the client’s computer, with the same access privileges 
as the user of the LICQ client. 

The scripting action lets the intruder gain user privileges on Windows machines. 
Microsoft Internet Explorer 5.01 and 6.0 allow remote attackers to execute arbitrary 
code via malformed Content-Disposition and Content-Type header fields that cause the 
application for the spoofed hie type to pass the hie back to the operating system for 
handling rather than raise an error message. This vulnerability may also be exploited 
through HTML formatted email. The action requires some social engineering to entice 
a user to visit a specially-formatted Web page. However, the action can work against 
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firewalled networks, since it requires only that internal users be able to browse the Web 
through the hrewall. 

Finally, the local buffer overflow action can exploit a multitude of existing vulner- 
abilities to let a user without administrative privileges gain them illegitimately. For the 
CVE number referenced in the table, the action exploits a buffer overflow flaw in the 
at program. The at program is a Linux utility for queueing shell commands for later 
execution. 

Some of the actions that we model have multiple instantiations in the CVE database. 
Eor example, the local buffer overflow action exploits a common coding error that occurs 
in many Linux programs. Each program vulnerable to local buffer overflow has a separate 
CVE entry, and all such entries correspond to the same action rule. The table lists only 
one example CVE identiher for each rule. 

4.1 Example Network Components 

Services, Vulnerabilities, and Connectivity. We specify the state of the network to 
include services running on each host, existing vulnerabilities, and connectivity between 
hosts. There are hve boolean variables for each host, specifying whether any of the three 
services are running and whether either of two other vulnerabilities are present on that 
host: 



Table 3. Variables specifying a host 



variable 


meaning 


w3svc^ 


IIS web service running on host h 


squidh 


Squid proxy mnning on host h 


licqh 


LICQ running on host h 


scripting/i 


HTML scripting is enabled on host h 


vul-atfc 


at executable vulnerable to overflow on host h 



The model of the target network includes connectivity information among the four 
hosts. The initial value of the connectivity relation R is shown the following table. An 
entry in the table corresponds to a pair of hosts {hi , / 12 ) ■ US and Squid listen on port 80 
and the LICQ client listens on port 5190, and the connectivity relation specifies which 
of these services can be reached remotely from other hosts. Each entry consists of three 
boolean values. The first value is ‘y’ if h\ and /12 are connected by a physical link, the 
second value is ‘y’ if hi can connect to ft -2 on port 80, and the third value is ‘y’ if hi can 
connect to /12 on port 5190. 

We use the connectivity relation to reflect the settings of the firewall as well as the 
existence of physical links. In the example, the intruder machine initially can reach only 
the Web server on port 80 due to a strict security policy on the external firewall. The 
internal firewall is initially used to restrict internal user activity by disallowing most 
outgoing connections. An important exception is that internal users are permitted to 
contact the Web server on port 80. 

In this example the connectivity relation stays unchanged throughout an attack. In 
general, the connectivity relation can change as a result of intruder actions. For example. 
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Table 4. Connectivity relation 



Host 


Intruder 


IIS Web Server 


Windows 


Linux 


Intruder 


y>yy 


y.yn 


n,n,n 


n,n,n 


IIS Web Server 


y,n,n 


y.yy 


y.y.y 


y.yA 


Windows 


n,n,n 


y.yn 


y.yy 


y.yA 


Linux 


n,n,n 


y.yn 


y.y.y 


y.yA 



an action may enable the intruder to compromise a firewall host and relax the firewall 
rules. 

Intrusion Detection System. A single network-hased intrusion detection system pro- 
tects the internal network. The paths between hosts Intruder and Web and between 
Windows and Linux are not monitored; the IDS can see the traffic between any other 
pair of hosts. There are no host-hased intrusion detection components. The IDS always 
detects the LICQ action, hut cannot see any of the other actions. The IDS is represented 
with a two-dimensional array of hits, shown in the following table. An entry in the table 
corresponds to a pair of hosts The value is ‘y ’ if the path between h i and ii2 is 

monitored by the IDS, and ’n’ otherwise. 

Intruder. The intruder’s store of knowledge consists of a single boolean variable ’scan’ . 
The variable indicates whether the intruder has successfully performed a port scan on 
the target network. For simplicity, we do not keep track of specific information gathered 
by the scan. It would not be difficult to do so, at the cost of increasing the size of the 
state space. 

Initially, the intruder has root access on his own machine Intruder, but no access 
to the other hosts. The ’scan’ variable is set to false. 

Actions. There are five action rules corresponding to the five actions in the intruder’s 
arsenal. Throughout the description, S is used to designate the source host and T the target 
host. R{S, T,p) says that host T is reachable from host S on port p. The abbreviation 
plvl{X) refers to the intruder’s current privilege level on host X. 

Recall that a specification of an action rule has four components: intruder precondi- 
tions, network preconditions, intruder effects, and network effects. The intruder precon- 
ditions component places conditions on the intruder’s store of knowledge and the privi- 
lege level required to launch the action. The network preconditions component specifies 



Table 5. IDS locations 



Host 


Intruder 


IIS Web 


Server 


Windows 


Linux 


Intruder 


n 


n 


y 


y 


IIS Web Server 


n 


n 


y 


y 


Windows 


y 


y 


n 


n 


Linux 


y 


y 


n 


n 
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conditions on target host state, network connectivity, trust, services, and vulnerabilities 
that must hold before launching the action. Finally, the intruder and network effects 
components list the effects of the action on the intruder’s state and on the network, 
respectively. 

Sometimes the intruder has no logical reason to execute a specific action, even if all 
technical preconditions for the action have been met. For instance, if the intruder’s current 
privileges include root access on the Web Server, the intruder would not need to execute 
the IIS buffer overflow action against the Web Server host. We have chosen to augment 
each action’s preconditions with a clause that disables the action in instances when 
the primary purpose of the action has been achieved by other means. This change is not 
strictly conservative, as it prevents the intruder from using an action for its secondary side 
effects. However, we feel that this is a reasonable price to pay for removing unnecessary 
transitions from the attack graphs. 



IIS Buffer Overflow. This remote-to-root action immediately gives a remote user a root 
shell on the target machine. 



action IIS -buffer-overflow is 
intruder preconditions 
plvl{S) > user 
plvl{T) < root 
network preconditions 
w3svct 

80) 

intruder effects 

plvl{T) := root 

network effects 

^w3svct 

end 



User-level privileges on host S 
No root-level privileges on host T 

Host T is running vulnerable IIS server 
Host T is reachable from S on port 80 

Root-level privileges on host T 

Host T is not running IIS 



Squid Port Scan. The Squid port scan action uses a misconfigured Squid web proxy to 
conduct a port scan of neighboring machines and report the results to the intruder. 



action squid-port-scan is 
intruder preconditions 

plvl{S) = user 
^scan 

network preconditions 

squids 
R{S,T, 80) 

intruder effects 

scan 

network effects 

0 

end 



User-level privileges on host S 
We have not yet performed a port scan 

Host T is running vulnerable Squid proxy 
Host T is reachable from S on port 80 

We have performed a port scan on the network 

No changes to the network component 
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LICQ Remote to User. This remote-to-user action immediately gives a remote user a 
user shell on the target machine. The action rule assumes that a port scan has been 
performed previously, modeling the fact that such actions typically become apparent to 
the intruder only after a scan reveals the possibility of exploiting software listening on 
lesser-known ports. 

action LICQ-remote-to-user is 
intruder preconditions 

plvl{S) > user 
plvl{T) = none 
scan 

network preconditions 

licq^- 

5190) 

intruder effects 

plvl{T) := user 

network effects 

0 

end 

Scripting Action. This remote-to-user action immediately gives a remote user a user shell 
on the target machine. The action rule does not model the social engineering required to 
get a user to download a specially-created Web page. 

action client-scripting is 
intruder preconditions 
plvl{S) > user 
plvl{T) = none 
network preconditions 
scriptings 
R{T, S, 80) 
intruder effects 
plvliT) := user 
network effects 
0 

end 

Local Buffer Overflow. If the intruder has acquired a user shell on the target machine, 
this action exploits a buffer overflow vulnerability on a setuid root file (in this case, the 
at executable) to gain root access. 



User-level privileges on host S 
No user-level privileges on host T 

HTML scripting is enabled on host T 
Host S is reachable from T on port 80 

User-level privileges on host T 

No changes to the network component 



User-level privileges on host S 

No user-level privileges on host T 

We have performed a port scan on the network 

Host T is running vulnerable LICQ software 
Host T is reachable from S on port 5190 

User-level privileges on host T 

No changes to the network component 



action local-setuid-buffer-overflow is 

intruder preconditions 

plvUT) = user User-level privileges on host T 
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network preconditions 

vul-aty 

intruder effects 

plvl{T) := root 

network effects 

0 

end 

4.2 Sample Attack Graphs 

Figure 4 shows a screenshot of the attack graph generated with our attack graph toolkit 
for the security property 



There is a vulnerable at executable 
Root-level privileges on host T 
No changes to the network component 



G {intruder.privilege[lin] < root) 

which states that the intruder will never attain root privileges on the Linux host. In 
Figure 4, a sample attack scenario is highlighted with solid square nodes, with each 
attack step identified by name and CVE number. Since the external firewall restricts 
most network connections from the outside, the intruder has no choice with respect to 
the initial step — it must be a buffer overflow action on the IIS Web server. Once the 
intruder has access to the Web server machine, his options expand. The highlighted 
scenario is the shortest route to success. The intruder uses the Web server machine to 
launch a port scan via the vulnerable Squid proxy running on the Linux host. The scan 
discovers that it is possible to obtain user privileges on the Linux host with the LICQ 
exploit. After that, a simple local buffer overflow gives the intruder administrative control 
over the Linux machine. The last transition in the action path is a bookkeeping step, 
signifying the intruder’s success. 

Any information explicitly represented in the model is available for inspection and 
analysis in the attack graph. For instance, with a few clicks we are able to highlight 



Begin 




Done! 



Highlighted scenario 



LICQ remote- 
-ocal buffer to-user 

overflow CVE-2001 
/E-2002-0004 



IIS buffer 
overflow 
CAN-2002-0364 
Squid portscan 
CVE-2001- 



Fig. 4. Example Attack Graph 
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portions of the graph “covered” by the intrusion detection system. Figure 5 shades the 
nodes where the IDS alarm has been sounded. These nodes lie on paths that use the 
LICQ action along a network path monitored by the IDS. It is clear that while a sub- 
stantial portion of the graph is covered by the IDS, the intruder can escape detection and 
still succeed by taking one of the paths on the right side of the graph. One such attack 
scenario is highlighted with square nodes in Figure 5. It is very similar to the attack 
scenario discussed in the previous paragraph, except that the LICQ action is launched 
from the internal Windows machine, where the intrusion detection system does not 
see it. To prepare for launching the LICQ action from the Windows machine, an addi- 
tional step is needed to obtain user privileges in the machine. For that, the intruder uses 
the client scripting exploit on the Windows host immediately after taking over the Web 
machine. 



Begin 




Local buffer 
overflow 
CVE-2002-0004 



Done! 



H Highlighted scenario 
^ Alarm has sounded 



IIS buffer 
overflow 
CAN-2002-0364 



Scripting remote- 
to-user 

CAN-2002-0193 



Squid portscan 
CVE-2001-1030 



LICQ remote- 
to-user 

CVE-2001-0439 



Fig. 5. Alternative Attack Scenario Avoiding the IDS 



4.3 Sample Attack Graph Analysis 

After generating an attack graph, we can use it to analyze potential effectiveness of 
various security improvements [16]. To demonstrate the analysis techniques, we expand 
the example from Sect. 4. 1 with an extra host User on the external network and several 
new actions. An authorized user W of the internal network owns the new host and uses 
it as a terminal to work remotely on the internal Windows host. The new actions permit 
the intruder to take over the host User, sniff user W’s login credentials, and log in 
to the internal Windows host using the stolen credentials. We omit the details of the 
new actions, as they are not essential to understanding the examples. Figure 6(a) shows 
the full graph for the modified example. The graph is significantly larger, reflecting the 
expanded number of choices available to the intruder. 

Single Action Removal. A simple kind of analysis determines the impact of removing 
one action from the intruder’s arsenal. Recall from Sect. 3 that each action is a triple 
(r, hs, ht), where hs G H is the host from which the attack is launched, ht G H is 
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the host targeted by the attack, and r is an action rule. The user specifies a set Arem of 
action triples to be removed from the attack graph. The toolkit deletes the transitions 
corresponding to each triple in the set Af-em from the graph and then removes the nodes 
that have become unreachable from the initial state. 

As demonstrated in Figure 6, this procedure can be repeated several times, reducing 
the size of the attack graph at each step. The full graph in Figure 6(a) has 362 states. 
Removing one of two ways the intruder can sniff user W’s login credentials produces 
the graph in Figure 6(b), with 213 states. Removing one of the local buffer overflow 
actions produces the graph in Figure 6(c), with 66 states. At each step, the user is able 
to judge visually the impact of removing a single action from the intruder’s arsenal. 

Critical Action Sets. Once an attack graph is generated, an approximation algorithm 
can find an approximately-optimal critical set of actions that will completely disconnect 
the initial state from states where the intruder has achieved his goals [16]. A related 
algorithm can find an approximately-optimal set of security measures that accomplish the 
same goal. With a single click, the user can invoke both of these exposure minimization 
algorithms. 

The effect of the critical action set algorithm on the modified example attack graph is 
shown in Figure 7(a) . The algorithm finds a critical action set of size 1 , containing the port 
scan action exploiting the Squid web proxy. The graph nodes and edges corresponding 
to actions in the critical set computed by the algorithm are highlighted in the toolkit 
by shading the relevant nodes. The shaded nodes are seen clearly when we zoom in to 
inspect a part of the graph on a larger scale (Figure 7(b)). 

Since the computed action set is always critical, removing every action triple in the 
set from the intruder’s arsenal is guaranteed to result in an empty attack graph. In the 
example, we might patch the Linux machine with a new version of the Squid proxy, 
thereby removing every action triple that uses the Squid port scan rule on the Linux 
machine from the intruder’s arsenal. 



5 Attack Graph Toolkit 

We have implemented a toolkit for generating and exploring attack graphs, using network 
attack models defined in Sect. 3. In this section we describe the toolkit and show several 
ways to integrate it with external data sources that supply information necessary to build 
a network attack model. Specifically, it is necessary to know the topology of the target 
network, configuration of the network hosts, and vulnerabilities present on the network. 
In addition, we require access to a database of attack rules to build the transition relation 
of the attack model. We could expect the user to specify all of the necessary information 
manually, but such a task is tedious, error-prone, and unrealistic for networks of more 
than a few nodes. 

We recommend deploying the attack graph toolkit in conjunction with information- 
gathering systems that supply some of the data automatically. We integrated the at- 
tack graph generator with two such systems, MITRE Corp’s Outpost and Lockheed 
Martin’s ANGI. We report on our experience with Outpost and ANGI in Sections 5.4 
and 5.5. 
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Fig. 6. Reducing Action Arsenal 
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(a) 



(b) 



Fig. 7. Finding Critical Action Sets 
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5.1 Toolkit Architecture 

Figure 8 shows the architecture of the attack graph toolkit. There are three main pieces: 
a network model builder, a scenario graph generator, and a graphical user interface 
(GUI). The network model builder takes as input information about network topology, 
configuration data for each networked host, and a library of attack rules. It constructs 
a finite model of the network suitable for automated analysis. The model is augmented 
with a security specification, which spells out the security requirements against which 
the attack graph is to be built. The model and the security specification then go to the 
second piece, the scenario graph generator. 




Fig. 8. Toolkit Architecture 

The scenario graph generator takes any finite model and correctness specihcation 
and produces a graph composed of possible executions of the model that violate the 
correctness specification. The model builder constructs the input to the graph generator 
so that the output will be the desired attack graph. The graphical user interface lets the 
user display and examine the graph. 

The model builder’s running time is linear in the size of the input specification, 
typically written in the XML format specified in Sect. 5.2. The algorithm in the scenario 
graph generator is linear in the size of the output scenario graph [16]. The slowest part 
of the toolkit is the algorithm that lays out the attack graph on screen. The algorithm 
uses the network simplex method to find optimal x-coordinates. The simplex method 
has exponential worst-case performance. The rest of the layout algorithm has cubic 
complexity. Thus, for large graphs it is sometimes necessary to run analysis algorithms 
without displaying the full graph on screen. 

5.2 The Model Builder 

Recall from Sect. 3 that a network attack model consists of six primary components: 

1 . //, a set of hosts connected to the network 

2. C, a connectivity relation expressing the network topology and inter-host reachabil- 
ity 

3. T, a relation expressing trust between hosts 
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4. I, a model of the intruder 

5. A, a set of individual attack actions 

6. Ids, a model of the intrusion detection system 

To construct each of the six components, the model builder needs to collect the 
following pieces of information. For the entire network, we need: 

1 . The set of hosts H 

2. The network topology and firewall rules, which together induce the connectivity 
relation C 

3. The initial state of the trust relation T: which hosts are trusted by other hosts prior 
to any intruder action 

Several pieces of data are required for each host h in the set H : 

4. A unique host identifier (usually name and network address) 

5. Operating system vendor and version 

6. Active network services with port numbers 

7. Common Vulnerabilities and Exposures IDs of all vulnerabilities present on h 

8. User- specific configuration parameters 

Finally, for each CVE vulnerability present on at least one host in the set H, we need: 

9. An attack rule with preconditions and effects 

We designed an XML-based format covering all of the information that the model builder 
requires. The XML format lets the user specify each piece of information manually or 
indicate that the data can be gathered automatically from an external source. A typical 
description of a host in XML is as follows: 

1 <host id= " typical-machine " ip= " 192 . 168 . 0 . 1 " > 

2 

3 <services> 

4 <ftp port="21"/> 

5 <W3SVC port="80"/> 

6 </services> 

7 

8 <connectivity> 

9 <remote id= "machinel " <ftp/> <W3SVC/> </remote> 

10 <remote id= "machine2 " > <sshd/> <W3SVC/> </remote> 

11 <remote id= "machine3 " > <sshd/> </remote> 

12 </connectivity> 

13 

14 <cve> 

15 <CAN-2002-0364/> 

16 <CAN-2002-0147/> 

17 </cve> 

18 

19 </host> 
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The example description provides the host name and network identification (line 
1), a list of active services with port numbers (lines 3-6), the part of the connectivity 
relation that involves the host (lines 8-12), and names of CVE and CVE-candidate (CAN) 
vulnerabilities known to be present on the host (lines 14-17). Connectivity is specified 
as a list of services that the host can reach on each remote machine. Lines 9-11 each 
specify one remote machine; e.g., typical-machine can reach machinal on ports 
assigned to the/tp and W3SVC (IIS Web Server) services. 

It is unrealistic to expect the user to collect and specify all of the data by hand. In 
Sections 5. 3-5. 5 we discuss three external data sources that supply some of the infor- 
mation automatically: the Nessus vulnerability scanner, MITRE Corp.’s Outpost, and 
Lockheed Martin’s ANGI. Whenever the model builder can get a specific piece of in- 
formation from one of these sources, a special tag is placed in the XML file. If Nessus, 
Outpost and ANGI are all available at the same time as sources of information, the above 
host description may look as follows: 

<host id= " typical-machine " ip= " | Outpost | " > 

<services source^ " | Outpost | " /> 

<connectivity source^ " | ANGI | " /> 

<cve source= " I Nessus I " /> 

</host> 

The model builder gets the host network address and the list of running services from 
Outpost, connectivity information from ANGI, and a list of existing vulnerabilities from 
Nessus. Once all of the relevant information is gathered, the model builder creates a 
finite model and encodes it in the input language of the scenario graph generator. The 
scenario graph generator then builds the attack graph. 

5.3 Attack Graphs with Nessus 

A savvy attacker might use one of the many widely available vulnerability scanners [4] to 
discover facts about the network and construct an attack scenario manually. Similarly, an 
attack graph generator can use a scanner to construct such scenarios automatically. Our 
attack graph toolkit works with the freeware vulnerability scanner Nessus [8] to gather 
information about reachable hosts, services running on those hosts, and any known 
exploitable vulnerabilities that can be detected remotely. 

The scanner has no internal knowledge of the target hosts, and will usually discover 
only part of the information necessary to construct a graph that includes every possible 
attack scenario. Using only an external vulnerability scanner to gather information can 
lead the system administrator to miss important attack scenarios. 

Nevertheless, the administrator can run vulnerability scanners against his own net- 
work to find out what a real attacker would discover. In the future, sophisticated intruders 
are likely to use attack graph generators to help them devise attack scenarios. As a part of 
network security strategy, we recommend running a vulnerability scanner in conjunction 
with an attack graph generator periodically to discover avenues of attack that are most 
likely to be exploited in practice. 
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Fig. 9. Outpost Architecture 

5.4 Attack Graphs with MITRE Outpost 

MITRE Corporation’s Outpost is a system for collecting, organizing, and maintaining 
security-related information on computer networks. It is a suite of inter- related security 
applications that share a common data model and a common data collection infrastruc- 
ture. The goal of Outpost is to provide a flexible and open environment for network and 
system administrators to monitor, control, and protect computer systems. 

At the center of the Outpost System is a data collection/probe execution engine that 
gathers specific configuration information from all of the systems within a network. The 
collected data is stored in a central database for analysis by the Outpost applications. 
Outpost collects data about individual hosts only, so it cannot provide information about 
network topology or attack rules. Since Outpost stores all of the data in a network- 
accessible SQL database, we retrieve the data directly from the database, without talking 
to the Outpost server, as shown in Figure 9. 

Currently Outpost works with SQL databases supported by Microsoft and Oracle. 
Both of these packages use a proprietary Application Programming Interface. The model 
builder includes an interface to each database, as well as a generic module that uses 
the Open DataBase Connectivity interface (ODBC) and works with any database that 
supports ODBC. Furthermore, it is easy to add a capability to interface with other types 
of databases. 

An Outpost-populated database contains a list of client hosts monitored by the Out- 
post server. For the model builder, the Outpost server can provide most of the required 
information about each individual host h, including: 

1 . A unique host identifier (usually name and network address) 

2. Operating system vendor and version 

3. Active network services with port numbers 

4. Common Vulnerabilities and Exposures IDs of all vulnerabilities present on h 

5. User- specific configuration parameters (e.g., is Javascript enabled for the user’s 
email client?) 

Outpost’s lists of CVE vulnerabilities are usually incomplete, and it does not keep 
track of some of the user-specific configuration parameters required by the attack graph 
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toolkit. Until these deficiencies are fixed, the user must provide the missing information 
manually. 

In the future, the Outpost server will inform the attack graph toolkit whenever changes 
are made to the database. The tighter integration with Outpost will enable attack graph 
toolkit to re-generate attack graphs automatically every time something changes in the 
network configuration. 

5.5 Attack Graphs with Lockheed’s ANGI 

Lockheed Martin Advanced Technology Laboratory’s (ATL) Next Generation Infras- 
tructure (ANGI) IR&D project is building systems that can be deployed in dynamic, 
distributed, and open network environments. ANGI collects local sensor information 
continuously on each network host. The sensor data is shared among the hosts, pro- 
viding dynamic awareness of the network status to each host. ANGI sensors gather 
information about host addresses, host programs and services, and network topology. In 
addition, ANGI supports vulnerability assessment sensors for threat analysis. 




Fig. 10. ANGI Network 



Two distinguishing features of ANGI are the ability to discover network topology 
changes dynamically and focus on technologies for pro-active, automated repair of net- 
work problems. ANGI is capable of providing the attack graph model builder with 
network topology information, which is not available in Outpost and is not gathered by 
Nessus. 

We tested our attack graph toolkit integrated with ANGI on a testbed of hve hosts 
with combinations of the five CVE vulnerabilities specihed for the example model in 
Chapter 4 (p. 352), and one adversary host. Figure 10 is a screenshot of the testbed 
network schematic. The intruder resides on the host lindenwold. Hosts trenton 
and mtholly run firewalls, which are initially disabled. We assume that the target of 
the intruder is the host shamong, which contains some critical resource. 

ANGI combines information about each host with data from firewall configuration 
files into a single XML document. To convert firewall rules into a reachability relation C 
accepted by the attack graph toolkit, ANGI uses a package developed at MITRE Corp. 
that computes network reachability from packet hlter data [14]. The XML file specifies 
explicitly five attack rules corresponding to the CVE vulnerabilities present on the hosts. 
ANGI then calls the model builder with the XML document and a security property as 
inputs. The security property specihes a guarantee of protection for the critical resource 
host shamong: 

G{intruder.privilege[shamong] < root) 
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The attack graph generator finds several potential attack scenarios. Figure 1 1 shows 
the attack graph as it is displayed by the graphical user interface. The graph consists of 
19 nodes with 28 edges. 




Fig. 11. ANGI Attack Graph - No Firewalls 



Exploring the attack graph reveals that several successful attack scenarios exploit the 
LICQ vulnerability on the host shamong. One such attack scenario is highlighted in 
Figure 1 1. As indicated in the “Path Info” pane on the left of Figure 11, the second step 
of the highlighted scenario exploits the LICQ vulnerability on shamong. This suggests 
a possible strategy for reducing the size of the graph. Using the ANGI interface, we 
enable the firewall on the host trenton, and add a rule that blocks all external traffic at 
trenton from reaching shamong on the LICQ port. ANGI then generates a new XML 
model file reflecting this change. The new graph demonstrates a significant reduction 
in network exposure from this relatively small change in network configuration. The 
modification reduces graph size to 7 nodes and 6 edges with only two possible paths. 
(Contrast this new graph with the attack graph shown in Figure 11, which has 19 nodes, 
28 edges, and 20 paths.) 
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Looking at the scenarios in this new graph, we discover that the attacker can still 
reach shamong hy first compromising the weh server on cherryhill. Since we 
do not want to disable the web server, we enable the firewall on mtholly and add 
a rule specifically blocking cherryhill’s access to the LICQ client on shamong. 
Yet another invocation of the attack graph generator on the modified model produces 
an empty attack graph and confirms that we have successfully safeguarded shamong 
while retaining the full functionality of the network. 



6 Related Work 

Many of the ideas that we propose to investigate have been suggested or considered in 
existing work in the intrusion detection field. This section surveys recent related work. 

Phillips and Swiler [13] propose the concept of attack graphs that is similar to the 
one described here. However, they take an “attack-centric” view of the system. Since we 
work with a general modeling language, we can express in our model both seemingly 
benign system events (such as failure of a link) and malicious events (such as attacks). 
Therefore, our attack graphs are more general than the one proposed by Phillips and 
Swiler. Swiler et al. describe a tool [19] for generating attack graphs based on their 
previous work. Their tool constructs the attack graph by forward exploration starting 
from the initial state. 

The advantage of using model checking instead of forward search is that the technique 
can be expanded to include liveness properties, which can model service guarantees in 
the face of malicious activity. For example, a model of a banking network could have a 
liveness security property such as 

G {CheckDeposited — > (F CheckCleared)) 

which specifies that every check deposited at a bank branch must eventually clear. 

Templeton and Levitt [20] propose a requires/provides model for attacks. The model 
links atomic attacks into scenarios, with earlier atomic attacks supplying the prerequisites 
for the later ones. Templeton and Levitt point out that relating seemingly innocuous sys- 
tem behavior to known attack scenarios can help discover new atomic attacks. However, 
they do not consider combining their attack scenarios into attack graphs. 

Cuppens and Ortalo [6] propose a declarative language (LAMBDA) for specifying at- 
tacks in terms of pre- and post-conditions. LAMBDA is a superset of the simple language 
we used to model attacks in our work. The language is modular and hierarchical; higher- 
level attacks can be described using lower-level attacks as components. LAMBDA also 
includes intrusion detection elements. Attack specifications includes information about 
the steps needed to detect the attack and the steps needed to verify that the attack has 
already been carried out. Using a database of attacks specified in LAMBDA, Cuppens 
and Miege [5] propose a method for alert correlation based on matching post-conditions 
of some attacks with pre-conditions of other attacks that may follow. In effect, they 
exploit the fact that alerts about attacks are more likely to be related if the corresponding 
attacks can be a part of the same attack scenario. 

Dacier [7] proposes the concept of privilege graphs. Each node in the privilege graph 
represents a set of privileges owned by the user; edges represent vulnerabilities. Privi- 
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lege graphs are then explored to construct attack state graphs, which represents different 
ways in which an intruder can reach a certain goal, such as root access on a host. He 
also defines a metric, called the mean effort to failure or METF, based on the attack 
state graphs. Orlato et al. describe an experimental evaluation of a framework based on 
these ideas [12]. At the surface, our notion of attack graphs seems similar to the one 
proposed by Dacier. However, as is the case with Phillips and Swiler, Dacier takes an 
“attack-centric” view of the world. As pointed out above, our attack graphs are more 
general. From the experiments conducted by Orlato et al. it appears that even for small 
examples the space required to construct attack state graphs becomes prohibitive. By 
basing our algorithm on model checking we take advantage of advances in representing 
large state spaces and can thus hope to represent large attack graphs. 

Ritchey and Ammann [15] also use model checking for vulnerability analysis of 
networks. They use the (unmodified) model checker SMV [18]. They can obtain only one 
counter-example, i.e., only one attack corresponding to an unsafe state. In contrast, we 
modified the model checker NuSMV to produce attack graphs, representing all possible 
attacks. We also described post-facto analyzes that can be performed on these attack 
graphs. These analysis techniques cannot be meaningfully performed on single attacks. 

Graph-based data structures have also been used in network intrusion detection sys- 
tems, such as NetSTAT [21]. There are two major components in NetSTAT, a set of 
probes placed at different points in the network and an analyzer. The analyzer processes 
events generated by the probes and generates alarms by consulting a network fact base 
and a scenario database. The network fact base contains information (such as connec- 
tivity) about the network being monitored. The scenario database has a directed graph 
representation of various atomic attacks. For example, the graph corresponding to an IP 
spoofing attack shows various steps that an intruder takes to mount that specific attack. 
The authors state that “in the analysis process the most critical operation is the generation 
of all possible instances of an attack scenario with respect to a given target network.” 

Ammann et. al. present a scalable attack graph representation [ 1 ] . They encode attack 
graphs as dependencies among exploits and security conditions, under the assumption 
of monotonicity. Informally, monotonicity means that no action an intruder can take 
interferes with the intruder’s ability to take any other actions. The authors treat vulnera- 
bilities, intruder access privileges, and network connectivity as atomic boolean attributes. 
Actions are treated as atomic transformations that, given a set of preconditions on the 
attributes, establish a set of postconditions. In this model, monotonicity means that (1) 
once a postcondition is satisfied, it can never become ’unsatisfied’, and (2) the negation 
operator cannot be used in expressing action preconditions. 

The authors show that under the monotonicity assumption it is possible to construct 
an efficient (low-order polynomial) attack graph representation that scales well. They 
present an efficient algorithm for extracting minimal attack scenarios from the represen- 
tation, and suggest that a standard graph algorithm can produce a critical set of actions 
that disconnects the goal state of the intruder from the initial state. 

This approach is less general than our treatment of attack graphs. In addition to 
the monotonicity requirement, it can handle only simple safety properties. Further, the 
compact attack graph representation is less explicit, and therefore harder for a human to 
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read. The advantage of the approach is that it has a worst-case hound on the size of the 
graph that is polynomial in the number of atomic attributes in the model, and therefore 
can scale better than full-fledged model checking to large networks. 



7 Summary and Current Status 

We have designed, implemented, and tested algorithms for automatically generating 
attack graphs and for performing different kinds of vulnerability analyses on them. We 
have built an attack graph toolkit to support our generation and analysis algorithms. 
The toolkit has an easy-to-use graphical user interface. We integrated our tools with 
external sources to populate our network attack model with host and vulnerability data 
automatically. 

We are in the process of specifying a library of actions based on a vulnerability 
database provided to us by SEI/CERT. This database has over 150 actions representing 
many published CVEs. We have preliminary results in using a subset of 30 of these 
actions as input to our model builder, allowing us to produce attack graphs with over 
300 nodes and 3000 edges in just a few minutes. Most telling, is that once graphs are 
that large, automated analysis, such as the kind we provide, is essential. 

With our current toolkit and our growing library of actions, we are now perform- 
ing systematic experiments: on different network configurations, with different subsets 
of actions, and for different attacker goals. The ultimate goal is to help the system 
administrator — by giving him a fast and completely automatic way to test out different 
system configurations (e.g., network connectivity, hrewall rules, services running on 
hosts), and by finding new attacks to which his system is vulnerable. 
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